Bug#929666: ITP: conmon -- An OCI container runtime monitor

[Reinhard Tartler]

On Tue, May 28, 2019 at 2:18 PM Birger Schacht 
wrote:

> On 5/28/19 6:49 PM, Reinhard Tartler wrote:
> > Thanks for working on this package.
> >
> > Do you plan to have this package team maintained in the golang team? If
> so,
> > please let us know where on salsa you maintain the source package. I may
> be
> > able to help out.
>
> I maintain the source package on
> https://salsa.debian.org/bisco-guest/conmon - but conmon is not a golang
> project, it is C. But if there is another team that package fits, I'd be
> happy to team maintain ;)
>

Thanks for the clarification.

I notice that you chose a packaging style that does not include
the upstream sources, which is not my personal preference.

Any chance to convince you to use a style that makes it possible
to use dgit(1)? If so, I'd be happy to help you with moving this
package to the "debian" namespace (formerly known as collab-maint)
which provides access to a audience and thus makes collaboration
easier, and to sponsor uploads as necessary.

Best,
-rt


-- 
regards,
Reinhard

Bug#929666: ITP: conmon -- An OCI container runtime monitor

[Reinhard Tartler]

On Tue, May 28, 2019 at 2:18 PM Birger Schacht 
wrote:

> On 5/28/19 6:49 PM, Reinhard Tartler wrote:
> > Thanks for working on this package.
> >
> > Do you plan to have this package team maintained in the golang team? If
> so,
> > please let us know where on salsa you maintain the source package. I may
> be
> > able to help out.
>
> I maintain the source package on
> https://salsa.debian.org/bisco-guest/conmon - but conmon is not a golang
> project, it is C. But if there is another team that package fits, I'd be
> happy to team maintain ;)
>

Thanks for the clarification.

I notice that you chose a packaging style that does not include
the upstream sources, which is not my personal preference.

Any chance to convince you to use a style that makes it possible
to use dgit(1)? If so, I'd be happy to help you with moving this
package to the "debian" namespace (formerly known as collab-maint)
which provides access to a audience and thus makes collaboration
easier, and to sponsor uploads as necessary.

Best,
-rt


-- 
regards,
Reinhard

Bug#929666: ITP: conmon -- An OCI container runtime monitor

[Reinhard Tartler]

Thanks for working on this package.

Do you plan to have this package team maintained in the golang team? If so,
please let us know where on salsa you maintain the source package. I may be
able to help out.

Best regards,
-rt

On Tue, May 28, 2019, 04:12 Birger Schacht  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Birger Schacht 
>
> * Package name: conmon
>   Version : 0.2.0
>   Upstream Author : Peter Hunt
> * URL : https://github.com/containers/conmon
> * License : Apache-2.0
>   Programming Lang: C
>   Description : An OCI container runtime monitor.
>
> Conmon is a monitoring program and communication tool between a
> container manager (like podman or CRI-O) and an OCI runtime (like runc
> or crun) for a single container.
> It is a run dependency for podman.
>
>

Bug#929666: ITP: conmon -- An OCI container runtime monitor

[Reinhard Tartler]

Thanks for working on this package.

Do you plan to have this package team maintained in the golang team? If so,
please let us know where on salsa you maintain the source package. I may be
able to help out.

Best regards,
-rt

On Tue, May 28, 2019, 04:12 Birger Schacht  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Birger Schacht 
>
> * Package name: conmon
>   Version : 0.2.0
>   Upstream Author : Peter Hunt
> * URL : https://github.com/containers/conmon
> * License : Apache-2.0
>   Programming Lang: C
>   Description : An OCI container runtime monitor.
>
> Conmon is a monitoring program and communication tool between a
> container manager (like podman or CRI-O) and an OCI runtime (like runc
> or crun) for a single container.
> It is a run dependency for podman.
>
>

Re: Do we want to Require or Recommend DH

[Reinhard Tartler]

On Tue, May 21, 2019, 03:41 Vincent Bernat  wrote:.

>
> Is there an example of a package where dh cannot be used? Making 96% of
> packages simpler and 4% of packages moderately more complex seems to be
> a good argument to uniformize our packaging practices towards dh.
> --
> Use the fundamental control flow constructs.
> - The Elements of Programming Style (Kernighan & Plauger)
>

I looked yesterday at the boxbackup source package and contemplated
converting it to dh from debhelper. I decided to not, because I'm having a
hard time seeing a significant simplification potential. Maybe I'm just not
seeing it?

Note that I orphaned the package quite some time ago, so feel welcome to
simplify it as much as possible on Salsa.

Best
-rt

>

Bug#922842: ITP: golang-github-containers-image -- Work with containers' images

[Reinhard Tartler]

On 4/29/19 8:09 AM, Cirujano Cuesta, Silvano wrote:

> On Mon, 2019-04-29 at 07:29 -0400, Reinhard Tartler wrote:
>> I'm having a hard time understanding what issue you are facing with and what 
>> you mean fix "fix manually". How are you building the package? Are you using 
>> git-buildpackage, sbuild or pbuilder? I'd
>> strongly recommend to do so, because if you were, I cannot see how you 
>> possibly could run into such issues.
> 
> I'm using none of them, I'm building "the hard way": in a container (from 
> Docker base image debian:sid-slim) with a script that runs the individual 
> steps and builds with 'dpkg-buildpackage'.
> It should be possible to build these packages this way, right? It usually 
> works.

I'm not familiar with building packages that way, please excuse my ignorance, 
but I'd rather focus on tools that I can actually use for uploading packages to 
Debian. I'm afraid that I'm probably unable to help you with this baseimage 
and/or approach to build packages.

> I prefer not to use too much magic (although using containers involves per-se 
> some magic) to better understand what's going on.

Same here. I took a look at 
https://github.com/debuerreotype/docker-debian-artifacts/blob/064f343bfa6ebf043aac2bbd4c870256cfe82f5a/sid/slim/Dockerfile
 and it does look pretty magical to me ;-)

There is not much magic with sbuild, please see https://wiki.debian.org/sbuild 
to get started. 

> What I meant with "fix manually" is executing "rm ostree/ostree_src.go" right 
> after patching and before building.
> 
> I don't know if the 'magic' of any of the mentioned tools is just silently 
> fixing the issue for you and that's why you are not facing it...
> 
>> In any case, a full buildlog, similar to what I attached, could be helpful. 
>> If English is a language barrier, try explaining in German.
> 
> I don't think that it's a language barrier.
> But possibly an expertise barrier: my expertise on building Debian packages 
> (specially for Go) is not as extensive as yours :-)

I don't claim extensive experience with Go, or Go packaging, but I think I do 
have a reasonable grasp of Debian packaging tools.

What I find puzzling in your buildlog is that while you do use 
dpkg-buildpackage, it fails to apply the quilt patches.

Good luck!
-rt

Bug#922842: ITP: golang-github-containers-image -- Work with containers' images

[Reinhard Tartler]

On 4/29/19 8:09 AM, Cirujano Cuesta, Silvano wrote:

> On Mon, 2019-04-29 at 07:29 -0400, Reinhard Tartler wrote:
>> I'm having a hard time understanding what issue you are facing with and what 
>> you mean fix "fix manually". How are you building the package? Are you using 
>> git-buildpackage, sbuild or pbuilder? I'd
>> strongly recommend to do so, because if you were, I cannot see how you 
>> possibly could run into such issues.
> 
> I'm using none of them, I'm building "the hard way": in a container (from 
> Docker base image debian:sid-slim) with a script that runs the individual 
> steps and builds with 'dpkg-buildpackage'.
> It should be possible to build these packages this way, right? It usually 
> works.

I'm not familiar with building packages that way, please excuse my ignorance, 
but I'd rather focus on tools that I can actually use for uploading packages to 
Debian. I'm afraid that I'm probably unable to help you with this baseimage 
and/or approach to build packages.

> I prefer not to use too much magic (although using containers involves per-se 
> some magic) to better understand what's going on.

Same here. I took a look at 
https://github.com/debuerreotype/docker-debian-artifacts/blob/064f343bfa6ebf043aac2bbd4c870256cfe82f5a/sid/slim/Dockerfile
 and it does look pretty magical to me ;-)

There is not much magic with sbuild, please see https://wiki.debian.org/sbuild 
to get started. 

> What I meant with "fix manually" is executing "rm ostree/ostree_src.go" right 
> after patching and before building.
> 
> I don't know if the 'magic' of any of the mentioned tools is just silently 
> fixing the issue for you and that's why you are not facing it...
> 
>> In any case, a full buildlog, similar to what I attached, could be helpful. 
>> If English is a language barrier, try explaining in German.
> 
> I don't think that it's a language barrier.
> But possibly an expertise barrier: my expertise on building Debian packages 
> (specially for Go) is not as extensive as yours :-)

I don't claim extensive experience with Go, or Go packaging, but I think I do 
have a reasonable grasp of Debian packaging tools.

What I find puzzling in your buildlog is that while you do use 
dpkg-buildpackage, it fails to apply the quilt patches.

Good luck!
-rt

Bug#923300: [containers/libpod] Package up podman for vanilla Debian (#1742)

[Reinhard Tartler]

On Mon, Apr 29, 2019 at 10:32 AM Silvano Cirujano Cuesta <
notificati...@github.com> wrote:

> I'll play with https://aptly.info to create a repository that backports
> all packages and dependencies required to build and run skopeo and buildah.
> I think I should be able to publish that on my
> https://people.debian.org/~siretart/ homepage.
>
> That would be helpful!
>
Done.

I've rebuild and backported the full stack in clean Debian/buster chroots,
so I'd expect the packages to work on the upcoming Debian 10 release, and
existing Debian "testing" and "unstable" laptops. To enable the repository,
do these steps as root:

$ curl https://people.debian.org/~siretart/rtbp/siretart-archive-key.asc |
apt-key add -

$ cat > /etc/apt/sources.list.d/rtbp.list <https://people.debian.org/~siretart/rtbp buster-backports main
deb-src https://people.debian.org/~siretart/rtbp buster-backports main
EOF

$ apt update && apt install buildah skopeo

Before using skopeo, please mind the note in
https://salsa.debian.org/go-team/packages/golang-github-containers-buildah/blob/d47ce7267b370614095d4a5a621d5eba473eb23d/debian/README.Debian

User Namespaces

===

Buildah requires a Linux Kernel with userspaces enabled. Debian

Kernels have that functionaly, but the local system administrator

needs to enable it manually, with a command like this:

sudo sysctl -w kernel.unprivileged_userns_clone=1

 -- Reinhard Tartler , Mon, 29 Apr 2019 20:37:02 -0400


Feedback, and assistance, preferably in form of PRs against the salsa
packaging branches would be most appreciated.

-- 
regards,
Reinhard

Bug#880199: [containers/libpod] Package up podman for vanilla Debian (#1742)

[Reinhard Tartler]

On Mon, Apr 29, 2019 at 10:32 AM Silvano Cirujano Cuesta <
notificati...@github.com> wrote:

> I'll play with https://aptly.info to create a repository that backports
> all packages and dependencies required to build and run skopeo and buildah.
> I think I should be able to publish that on my
> https://people.debian.org/~siretart/ homepage.
>
> That would be helpful!
>
Done.

I've rebuild and backported the full stack in clean Debian/buster chroots,
so I'd expect the packages to work on the upcoming Debian 10 release, and
existing Debian "testing" and "unstable" laptops. To enable the repository,
do these steps as root:

$ curl https://people.debian.org/~siretart/rtbp/siretart-archive-key.asc |
apt-key add -

$ cat > /etc/apt/sources.list.d/rtbp.list <https://people.debian.org/~siretart/rtbp buster-backports main
deb-src https://people.debian.org/~siretart/rtbp buster-backports main
EOF

$ apt update && apt install buildah skopeo

Before using skopeo, please mind the note in
https://salsa.debian.org/go-team/packages/golang-github-containers-buildah/blob/d47ce7267b370614095d4a5a621d5eba473eb23d/debian/README.Debian

User Namespaces

===

Buildah requires a Linux Kernel with userspaces enabled. Debian

Kernels have that functionaly, but the local system administrator

needs to enable it manually, with a command like this:

sudo sysctl -w kernel.unprivileged_userns_clone=1

 -- Reinhard Tartler , Mon, 29 Apr 2019 20:37:02 -0400


Feedback, and assistance, preferably in form of PRs against the salsa
packaging branches would be most appreciated.

-- 
regards,
Reinhard

Bug#923300: ITP: golang-github-openshift-imagebuilder -- Builds Dockerfile using the Docker client

[Reinhard Tartler]

On 4/29/19 10:24 AM, Cirujano Cuesta, Silvano wrote:
>> I actually went ahead and implement this solution. The result can be seen at
>> https://salsa.debian.org/go-team/packages/golang-github-openshift-imagebuilder
> 
> The project doesn't appear to be there, isn't it public?

My bad, I've updated the project privacy settings to make the project public.
You should have access now.

Thank you for pointing that out, that was a mistake on my side.

-rt

Bug#923300: ITP: golang-github-openshift-imagebuilder -- Builds Dockerfile using the Docker client

[Reinhard Tartler]

On 4/29/19 10:24 AM, Cirujano Cuesta, Silvano wrote:
>> I actually went ahead and implement this solution. The result can be seen at
>> https://salsa.debian.org/go-team/packages/golang-github-openshift-imagebuilder
> 
> The project doesn't appear to be there, isn't it public?

My bad, I've updated the project privacy settings to make the project public.
You should have access now.

Thank you for pointing that out, that was a mistake on my side.

-rt

Bug#922842: ITP: golang-github-containers-image -- Work with containers' images

[Reinhard Tartler]

I'm having a hard time understanding what issue you are facing with and what 
you mean fix "fix manually". How are you building the package? Are you using 
git-buildpackage, sbuild or pbuilder? I'd strongly recommend to do so, because 
if you were, I cannot see how you possibly could run into such issues.

In any case, a full buildlog, similar to what I attached, could be helpful. If 
English is a language barrier, try explaining in German.

Best,
Reinhard

On April 29, 2019 7:21:09 AM EDT, "Cirujano Cuesta, Silvano" 
 wrote:
>Commit c17b0346 is changing the patching of the 'ostree' directory in a
>way that generates an invalid Go package.
>
>Instead of removing 'ostree/ostree_src.go', it's replacing it with an
>empty file that breaks 'go build'.
>
>If I manually fix it, it builds successfully.
>
>Cheers,
>  Silvano
>
>[1]
>https://salsa.debian.org/go-team/packages/golang-github-containers-image/commit/c17b0346163f88028e5675600865ac2eb95e051d

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#922842: ITP: golang-github-containers-image -- Work with containers' images

[Reinhard Tartler]

I'm having a hard time understanding what issue you are facing with and what 
you mean fix "fix manually". How are you building the package? Are you using 
git-buildpackage, sbuild or pbuilder? I'd strongly recommend to do so, because 
if you were, I cannot see how you possibly could run into such issues.

In any case, a full buildlog, similar to what I attached, could be helpful. If 
English is a language barrier, try explaining in German.

Best,
Reinhard

On April 29, 2019 7:21:09 AM EDT, "Cirujano Cuesta, Silvano" 
 wrote:
>Commit c17b0346 is changing the patching of the 'ostree' directory in a
>way that generates an invalid Go package.
>
>Instead of removing 'ostree/ostree_src.go', it's replacing it with an
>empty file that breaks 'go build'.
>
>If I manually fix it, it builds successfully.
>
>Cheers,
>  Silvano
>
>[1]
>https://salsa.debian.org/go-team/packages/golang-github-containers-image/commit/c17b0346163f88028e5675600865ac2eb95e051d

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#928083: ITP: golang-github-containers-buildah -- A tool that facilitates building OCI images

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-containers-buildah
  Version : 1.7.1-1
  Upstream Author : Containers
* URL : https://github.com/containers/buildah
* License : Apache-2.0
  Programming Lang: Go
  Description : A tool that facilitates building OCI images

 The Buildah package provides a command line tool that can be used to
  - create a working container, either from scratch or using an image
as a starting point
  - create an image, either from a working container or
via the instructions in a Dockerfile
  - images can be built in either the OCI image format or the
traditional upstream docker image format mount a working
container's root filesystem for manipulation
  - unmount  a working container's root filesystem
  - use the updated contents of a container's root filesystem as a
filesystem layer to create a new image
  - delete a working container or an image
  - rename a local container Buildah

This package is going to be maintained within the go team on salsa:
https://salsa.debian.org/go-team/packages/golang-github-containers-image

Bug#928083: ITP: golang-github-containers-buildah -- A tool that facilitates building OCI images

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-containers-buildah
  Version : 1.7.1-1
  Upstream Author : Containers
* URL : https://github.com/containers/buildah
* License : Apache-2.0
  Programming Lang: Go
  Description : A tool that facilitates building OCI images

 The Buildah package provides a command line tool that can be used to
  - create a working container, either from scratch or using an image
as a starting point
  - create an image, either from a working container or
via the instructions in a Dockerfile
  - images can be built in either the OCI image format or the
traditional upstream docker image format mount a working
container's root filesystem for manipulation
  - unmount  a working container's root filesystem
  - use the updated contents of a container's root filesystem as a
filesystem layer to create a new image
  - delete a working container or an image
  - rename a local container Buildah

This package is going to be maintained within the go team on salsa:
https://salsa.debian.org/go-team/packages/golang-github-containers-image

Bug#928083: ITP: golang-github-containers-buildah -- A tool that facilitates building OCI images

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-containers-buildah
  Version : 1.7.1-1
  Upstream Author : Containers
* URL : https://github.com/containers/buildah
* License : Apache-2.0
  Programming Lang: Go
  Description : A tool that facilitates building OCI images

 The Buildah package provides a command line tool that can be used to
  - create a working container, either from scratch or using an image
as a starting point
  - create an image, either from a working container or
via the instructions in a Dockerfile
  - images can be built in either the OCI image format or the
traditional upstream docker image format mount a working
container's root filesystem for manipulation
  - unmount  a working container's root filesystem
  - use the updated contents of a container's root filesystem as a
filesystem layer to create a new image
  - delete a working container or an image
  - rename a local container Buildah

This package is going to be maintained within the go team on salsa:
https://salsa.debian.org/go-team/packages/golang-github-containers-image

Re: Bug#922842: ITP: golang-github-containers-image -- Work with containers' images

[Reinhard Tartler]

Hi Silvano,

thanks for your interest in my packaging. Unfortunately at this point, I
don't have a public repository with packages to test. TBH, I was hoping
that ftp-master would process my uploads in a more timely manner. I've been
using "sbuild --extra-package=DIR" option to iteratively build the package
in right dependency order, but I am with you that this is a tedious process.

I'm afraid that at this point you'll have to build all of them yourself.
I'm sorry that I don't have a better answer for you at this time.

Best,
-rt


On Thu, Apr 25, 2019 at 3:09 AM Cirujano Cuesta, Silvano <
silvano.cirujano-cue...@siemens.com> wrote:

> Hi Reinhard,
>
> I'd like to test Skopeo (one of the packages that you are added to WNPP).
> But in order to do so I need to build this package first.
> And in order to do so I need to build other WNPP packages...
>
> So my question is, are there any support tools that I don't know of taking
> care of it all?
> Or a repository that can be simply added to sources.list?
> Or do I have to build them all myself?
>

Bug#927042: unblock: gpac/gpac 0.5.2-426-gc5ad4e4+dfsg5-5

[Reinhard Tartler]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package gpac

Moritz has kindly pointed out and backported the relevant patches from upstream
that fixes this issue. Here is the relevant part of debian/changelog:

  * Bug fix: "CVE-2019-11222: Buffer-overflow in gf_bin128_parse", thanks
to Salvatore Bonaccorso (Closes: #926961).
  * Bug fix: "CVE-2019-11221: buffer-overflow issue in gf_import_message()
in media_import.c", thanks to Salvatore Bonaccorso (Closes: #926963).

unblock gpac/gpac 0.5.2-426-gc5ad4e4+dfsg5-5

Thanks for considering.
-rt

diff -Nru gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/changelog 
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/changelog
--- gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/changelog  2019-04-01 
17:07:02.0 -0400
+++ gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/changelog  2019-04-13 
16:41:15.0 -0400
@@ -1,3 +1,13 @@
+gpac (0.5.2-426-gc5ad4e4+dfsg5-5) unstable; urgency=medium
+
+  [ Moritz Muehlenhoff ]
+  * Bug fix: "CVE-2019-11222: Buffer-overflow in gf_bin128_parse", thanks
+to Salvatore Bonaccorso (Closes: #926961).
+  * Bug fix: "CVE-2019-11221: buffer-overflow issue in gf_import_message()
+in media_import.c", thanks to Salvatore Bonaccorso (Closes: #926963).
+
+ -- Reinhard Tartler   Sat, 13 Apr 2019 16:41:15 -0400
+
 gpac (0.5.2-426-gc5ad4e4+dfsg5-4.1) unstable; urgency=medium

   * CVE-2018-7752 (Closes: #892526)
diff -Nru gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2019-11221.patch 
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2019-11221.patch
--- gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2019-11221.patch   
1969-12-31 19:00:00.0 -0500
+++ gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2019-11221.patch   
2019-04-13 16:41:15.0 -0400
@@ -0,0 +1,180 @@
+From f4616202e5578e65746cf7e7ceeba63bee1b094b Mon Sep 17 00:00:00 2001
+From: Aurelien David 
+Date: Thu, 11 Apr 2019 14:18:58 +0200
+Subject: [PATCH] fix a bunch of vsprintf -> vsnprintf
+
+closes #1203
+---
+ applications/mp4client/main.c |  2 +-
+ applications/osmo4_sym/osmo4_view.cpp |  2 +-
+ src/media_tools/media_export.c|  2 +-
+ src/media_tools/media_import.c|  2 +-
+ src/scene_manager/loader_bt.c |  4 ++--
+ src/scene_manager/loader_isom.c   |  2 +-
+ src/scene_manager/loader_qt.c |  2 +-
+ src/scene_manager/loader_svg.c|  8 
+ src/scene_manager/loader_xmt.c| 14 +++---
+ src/scene_manager/swf_parse.c |  6 +++---
+ src/scene_manager/swf_svg.c   |  2 +-
+ src/scenegraph/xbl_process.c  |  2 +-
+ src/utils/alloc.c |  2 +-
+ src/utils/xml_parser.c| 24 +---
+ 15 files changed, 49 insertions(+), 47 deletions(-)
+
+--- a/applications/mp4client/main.c
 b/applications/mp4client/main.c
+@@ -1023,7 +1023,7 @@ static void on_gpac_log(void *cbk, u32 l
+
+   if (rti_logs && (lm & GF_LOG_RTI)) {
+   char szMsg[2048];
+-  vsprintf(szMsg, fmt, list);
++  vsnprintf(szMsg, 2048, fmt, list);
+   UpdateRTInfo(szMsg + 6 /*"[RTI] "*/);
+   } else {
+   if (log_time_start) {
+--- a/src/media_tools/media_export.c
 b/src/media_tools/media_export.c
+@@ -57,7 +57,7 @@ static GF_Err gf_export_message(GF_Media
+   va_list args;
+   char szMsg[1024];
+   va_start(args, format);
+-  vsprintf(szMsg, format, args);
++  vsnprintf(szMsg, 1024, format, args);
+   va_end(args);
+   GF_LOG((u32) (e ? GF_LOG_ERROR : GF_LOG_WARNING), 
GF_LOG_AUTHOR, ("%s\n", szMsg) );
+   }
+--- a/src/media_tools/media_import.c
 b/src/media_tools/media_import.c
+@@ -50,7 +50,7 @@ GF_Err gf_import_message(GF_MediaImporte
+   va_list args;
+   char szMsg[1024];
+   va_start(args, format);
+-  vsprintf(szMsg, format, args);
++  vsnprintf(szMsg, 1024, format, args);
+   va_end(args);
+   GF_LOG((u32) (e ? GF_LOG_WARNING : GF_LOG_INFO), GF_LOG_AUTHOR, 
("%s\n", szMsg) );
+   }
+--- a/src/scene_manager/loader_bt.c
 b/src/scene_manager/loader_bt.c
+@@ -121,7 +121,7 @@ static GF_Err gf_bt_report(GF_BTParser *
+   char szMsg[2048];
+   va_list args;
+   va_start(args, format);
+-  vsprintf(szMsg, format, args);
++  vsnprintf(szMsg, 2048, format, args);
+   va_end(args);
+   GF_LOG((u32) (e ? GF_LOG_ERROR : GF_LOG_WARNING), 
GF_LOG_PARSER, ("[BT/WRL Parsing] %s (line %d)\n", szMsg, parser->line));
+   }
+--- a/src/scene_manager/loader_isom.c
 b/src/scene_manager/loader_isom.c
+@@ -144,7 +144,7 @@ static void mp4_report(GF_SceneLoader *l
+  

Bug#927042: unblock: gpac/gpac 0.5.2-426-gc5ad4e4+dfsg5-5

[Reinhard Tartler]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package gpac

Moritz has kindly pointed out and backported the relevant patches from upstream
that fixes this issue. Here is the relevant part of debian/changelog:

  * Bug fix: "CVE-2019-11222: Buffer-overflow in gf_bin128_parse", thanks
to Salvatore Bonaccorso (Closes: #926961).
  * Bug fix: "CVE-2019-11221: buffer-overflow issue in gf_import_message()
in media_import.c", thanks to Salvatore Bonaccorso (Closes: #926963).

unblock gpac/gpac 0.5.2-426-gc5ad4e4+dfsg5-5

Thanks for considering.
-rt

diff -Nru gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/changelog 
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/changelog
--- gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/changelog  2019-04-01 
17:07:02.0 -0400
+++ gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/changelog  2019-04-13 
16:41:15.0 -0400
@@ -1,3 +1,13 @@
+gpac (0.5.2-426-gc5ad4e4+dfsg5-5) unstable; urgency=medium
+
+  [ Moritz Muehlenhoff ]
+  * Bug fix: "CVE-2019-11222: Buffer-overflow in gf_bin128_parse", thanks
+to Salvatore Bonaccorso (Closes: #926961).
+  * Bug fix: "CVE-2019-11221: buffer-overflow issue in gf_import_message()
+in media_import.c", thanks to Salvatore Bonaccorso (Closes: #926963).
+
+ -- Reinhard Tartler   Sat, 13 Apr 2019 16:41:15 -0400
+
 gpac (0.5.2-426-gc5ad4e4+dfsg5-4.1) unstable; urgency=medium

   * CVE-2018-7752 (Closes: #892526)
diff -Nru gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2019-11221.patch 
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2019-11221.patch
--- gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2019-11221.patch   
1969-12-31 19:00:00.0 -0500
+++ gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2019-11221.patch   
2019-04-13 16:41:15.0 -0400
@@ -0,0 +1,180 @@
+From f4616202e5578e65746cf7e7ceeba63bee1b094b Mon Sep 17 00:00:00 2001
+From: Aurelien David 
+Date: Thu, 11 Apr 2019 14:18:58 +0200
+Subject: [PATCH] fix a bunch of vsprintf -> vsnprintf
+
+closes #1203
+---
+ applications/mp4client/main.c |  2 +-
+ applications/osmo4_sym/osmo4_view.cpp |  2 +-
+ src/media_tools/media_export.c|  2 +-
+ src/media_tools/media_import.c|  2 +-
+ src/scene_manager/loader_bt.c |  4 ++--
+ src/scene_manager/loader_isom.c   |  2 +-
+ src/scene_manager/loader_qt.c |  2 +-
+ src/scene_manager/loader_svg.c|  8 
+ src/scene_manager/loader_xmt.c| 14 +++---
+ src/scene_manager/swf_parse.c |  6 +++---
+ src/scene_manager/swf_svg.c   |  2 +-
+ src/scenegraph/xbl_process.c  |  2 +-
+ src/utils/alloc.c |  2 +-
+ src/utils/xml_parser.c| 24 +---
+ 15 files changed, 49 insertions(+), 47 deletions(-)
+
+--- a/applications/mp4client/main.c
 b/applications/mp4client/main.c
+@@ -1023,7 +1023,7 @@ static void on_gpac_log(void *cbk, u32 l
+
+   if (rti_logs && (lm & GF_LOG_RTI)) {
+   char szMsg[2048];
+-  vsprintf(szMsg, fmt, list);
++  vsnprintf(szMsg, 2048, fmt, list);
+   UpdateRTInfo(szMsg + 6 /*"[RTI] "*/);
+   } else {
+   if (log_time_start) {
+--- a/src/media_tools/media_export.c
 b/src/media_tools/media_export.c
+@@ -57,7 +57,7 @@ static GF_Err gf_export_message(GF_Media
+   va_list args;
+   char szMsg[1024];
+   va_start(args, format);
+-  vsprintf(szMsg, format, args);
++  vsnprintf(szMsg, 1024, format, args);
+   va_end(args);
+   GF_LOG((u32) (e ? GF_LOG_ERROR : GF_LOG_WARNING), 
GF_LOG_AUTHOR, ("%s\n", szMsg) );
+   }
+--- a/src/media_tools/media_import.c
 b/src/media_tools/media_import.c
+@@ -50,7 +50,7 @@ GF_Err gf_import_message(GF_MediaImporte
+   va_list args;
+   char szMsg[1024];
+   va_start(args, format);
+-  vsprintf(szMsg, format, args);
++  vsnprintf(szMsg, 1024, format, args);
+   va_end(args);
+   GF_LOG((u32) (e ? GF_LOG_WARNING : GF_LOG_INFO), GF_LOG_AUTHOR, 
("%s\n", szMsg) );
+   }
+--- a/src/scene_manager/loader_bt.c
 b/src/scene_manager/loader_bt.c
+@@ -121,7 +121,7 @@ static GF_Err gf_bt_report(GF_BTParser *
+   char szMsg[2048];
+   va_list args;
+   va_start(args, format);
+-  vsprintf(szMsg, format, args);
++  vsnprintf(szMsg, 2048, format, args);
+   va_end(args);
+   GF_LOG((u32) (e ? GF_LOG_ERROR : GF_LOG_WARNING), 
GF_LOG_PARSER, ("[BT/WRL Parsing] %s (line %d)\n", szMsg, parser->line));
+   }
+--- a/src/scene_manager/loader_isom.c
 b/src/scene_manager/loader_isom.c
+@@ -144,7 +144,7 @@ static void mp4_report(GF_SceneLoader *l
+  

Bug#927042: unblock: gpac/gpac 0.5.2-426-gc5ad4e4+dfsg5-5

[Reinhard Tartler]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package gpac

Moritz has kindly pointed out and backported the relevant patches from upstream
that fixes this issue. Here is the relevant part of debian/changelog:

  * Bug fix: "CVE-2019-11222: Buffer-overflow in gf_bin128_parse", thanks
to Salvatore Bonaccorso (Closes: #926961).
  * Bug fix: "CVE-2019-11221: buffer-overflow issue in gf_import_message()
in media_import.c", thanks to Salvatore Bonaccorso (Closes: #926963).

unblock gpac/gpac 0.5.2-426-gc5ad4e4+dfsg5-5

Thanks for considering.
-rt

diff -Nru gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/changelog 
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/changelog
--- gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/changelog  2019-04-01 
17:07:02.0 -0400
+++ gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/changelog  2019-04-13 
16:41:15.0 -0400
@@ -1,3 +1,13 @@
+gpac (0.5.2-426-gc5ad4e4+dfsg5-5) unstable; urgency=medium
+
+  [ Moritz Muehlenhoff ]
+  * Bug fix: "CVE-2019-11222: Buffer-overflow in gf_bin128_parse", thanks
+to Salvatore Bonaccorso (Closes: #926961).
+  * Bug fix: "CVE-2019-11221: buffer-overflow issue in gf_import_message()
+in media_import.c", thanks to Salvatore Bonaccorso (Closes: #926963).
+
+ -- Reinhard Tartler   Sat, 13 Apr 2019 16:41:15 -0400
+
 gpac (0.5.2-426-gc5ad4e4+dfsg5-4.1) unstable; urgency=medium

   * CVE-2018-7752 (Closes: #892526)
diff -Nru gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2019-11221.patch 
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2019-11221.patch
--- gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2019-11221.patch   
1969-12-31 19:00:00.0 -0500
+++ gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2019-11221.patch   
2019-04-13 16:41:15.0 -0400
@@ -0,0 +1,180 @@
+From f4616202e5578e65746cf7e7ceeba63bee1b094b Mon Sep 17 00:00:00 2001
+From: Aurelien David 
+Date: Thu, 11 Apr 2019 14:18:58 +0200
+Subject: [PATCH] fix a bunch of vsprintf -> vsnprintf
+
+closes #1203
+---
+ applications/mp4client/main.c |  2 +-
+ applications/osmo4_sym/osmo4_view.cpp |  2 +-
+ src/media_tools/media_export.c|  2 +-
+ src/media_tools/media_import.c|  2 +-
+ src/scene_manager/loader_bt.c |  4 ++--
+ src/scene_manager/loader_isom.c   |  2 +-
+ src/scene_manager/loader_qt.c |  2 +-
+ src/scene_manager/loader_svg.c|  8 
+ src/scene_manager/loader_xmt.c| 14 +++---
+ src/scene_manager/swf_parse.c |  6 +++---
+ src/scene_manager/swf_svg.c   |  2 +-
+ src/scenegraph/xbl_process.c  |  2 +-
+ src/utils/alloc.c |  2 +-
+ src/utils/xml_parser.c| 24 +---
+ 15 files changed, 49 insertions(+), 47 deletions(-)
+
+--- a/applications/mp4client/main.c
 b/applications/mp4client/main.c
+@@ -1023,7 +1023,7 @@ static void on_gpac_log(void *cbk, u32 l
+
+   if (rti_logs && (lm & GF_LOG_RTI)) {
+   char szMsg[2048];
+-  vsprintf(szMsg, fmt, list);
++  vsnprintf(szMsg, 2048, fmt, list);
+   UpdateRTInfo(szMsg + 6 /*"[RTI] "*/);
+   } else {
+   if (log_time_start) {
+--- a/src/media_tools/media_export.c
 b/src/media_tools/media_export.c
+@@ -57,7 +57,7 @@ static GF_Err gf_export_message(GF_Media
+   va_list args;
+   char szMsg[1024];
+   va_start(args, format);
+-  vsprintf(szMsg, format, args);
++  vsnprintf(szMsg, 1024, format, args);
+   va_end(args);
+   GF_LOG((u32) (e ? GF_LOG_ERROR : GF_LOG_WARNING), 
GF_LOG_AUTHOR, ("%s\n", szMsg) );
+   }
+--- a/src/media_tools/media_import.c
 b/src/media_tools/media_import.c
+@@ -50,7 +50,7 @@ GF_Err gf_import_message(GF_MediaImporte
+   va_list args;
+   char szMsg[1024];
+   va_start(args, format);
+-  vsprintf(szMsg, format, args);
++  vsnprintf(szMsg, 1024, format, args);
+   va_end(args);
+   GF_LOG((u32) (e ? GF_LOG_WARNING : GF_LOG_INFO), GF_LOG_AUTHOR, 
("%s\n", szMsg) );
+   }
+--- a/src/scene_manager/loader_bt.c
 b/src/scene_manager/loader_bt.c
+@@ -121,7 +121,7 @@ static GF_Err gf_bt_report(GF_BTParser *
+   char szMsg[2048];
+   va_list args;
+   va_start(args, format);
+-  vsprintf(szMsg, format, args);
++  vsnprintf(szMsg, 2048, format, args);
+   va_end(args);
+   GF_LOG((u32) (e ? GF_LOG_ERROR : GF_LOG_WARNING), 
GF_LOG_PARSER, ("[BT/WRL Parsing] %s (line %d)\n", szMsg, parser->line));
+   }
+--- a/src/scene_manager/loader_isom.c
 b/src/scene_manager/loader_isom.c
+@@ -144,7 +144,7 @@ static void mp4_report(GF_SceneLoader *l
+  

Accepted gpac 0.7.1+dfsg1-3 (source) into experimental

[Reinhard Tartler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 13 Apr 2019 16:52:04 -0400
Source: gpac
Architecture: source
Version: 0.7.1+dfsg1-3
Distribution: experimental
Urgency: medium
Maintainer: Debian Multimedia Maintainers 
Changed-By: Reinhard Tartler 
Closes: 926961 926963
Changes:
 gpac (0.7.1+dfsg1-3) experimental; urgency=medium
 .
   * Merge security patches from unstable
 Closes: #926961, Closes: #926963
Checksums-Sha1:
 9666e1ad1d5edc9b7a09be98e4c554dcc600e445 2691 gpac_0.7.1+dfsg1-3.dsc
 a20e01d9353bf4dfda445647456084f7d0b66f5d 45448 gpac_0.7.1+dfsg1-3.debian.tar.xz
Checksums-Sha256:
 26276b5e08112751122aaad4ae22e826d3552abeb75541450b105e47ef665068 2691 
gpac_0.7.1+dfsg1-3.dsc
 8b7036374d56a9c9f0dfb3e3a757dac301ecc45ef39d331161bff596bedb9d85 45448 
gpac_0.7.1+dfsg1-3.debian.tar.xz
Files:
 a15eb462cc2ce70ca570e33e2aeb528e 2691 graphics optional gpac_0.7.1+dfsg1-3.dsc
 bda1c51a0d0ce0f13287dbbd9e1c6e7e 45448 graphics optional 
gpac_0.7.1+dfsg1-3.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQJIBAEBCgAyFiEEMN59F2OrlFLH4IJQSadpd5QoJssFAlyyTq4UHHNpcmV0YXJ0
QHRhdXdhcmUuZGUACgkQSadpd5QoJssD3Q/+KmZz2HFWLTN/2S1ljlWjCzCuJPt8
+CimxsyDPGoMFR4GElCcEdJK/Xi+poAINYlHARxHGJw5ZtbhG7YppaLO2HfNUBQz
Hng7TxE3jlgj6ExeUnRLiu/gcq2COFn1+j9HmdWA1XmejxW2i6UG7rsGuAgii97L
vqpQJmxAJNWmM+fxVJdpkWed+zUb/iB6byhaBSTzdUVcaotu25GPwSEvWkX+jmMC
Xr2GjqDQA/+BpqCfhA8zCQgRDdErZlvUDYfdXTyO3y20VuR+2xI7fKeJHcYVJACe
BoEiE0oipfXhtElzsns7ufHH4oZobs+3mixTxID1BHiZGKuszB1jCDF+dcOwXE+G
rrENJf8kOje3EHiE9i9DMZHQ0nYclqQXlcZrsAXXOya8H0Z+Gwg9i7bPhxHQYS2J
qJErMrAYBLXrr8TwKN6rNFAk1MPGMNZU7k6p5tzS4AgRuv5lMUlQ2sMRV3RPPsKp
qtbAhnMuu5Ebasn0Ro9Mt3T7LznRvTXQHY9UkyIO9rukCZwnR9Hc5eVkL5DJ483P
uZGzsJj0If8SSg5VZdSunACkWEWw7p97wEmaJSAA+mwunyZDNX0cKv0WrzaCJfDc
Claqf4YgPxtQcklKnq4ZAmDUi5utd+ZBms75oCv06/NH8c2ZKWIpaZVot4bI8jal
sRwe53FHxouMQkg=
=jmyP
-END PGP SIGNATURE-

Accepted gpac 0.7.1+dfsg1-3 (source) into experimental

[Reinhard Tartler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 13 Apr 2019 16:52:04 -0400
Source: gpac
Architecture: source
Version: 0.7.1+dfsg1-3
Distribution: experimental
Urgency: medium
Maintainer: Debian Multimedia Maintainers 
Changed-By: Reinhard Tartler 
Closes: 926961 926963
Changes:
 gpac (0.7.1+dfsg1-3) experimental; urgency=medium
 .
   * Merge security patches from unstable
 Closes: #926961, Closes: #926963
Checksums-Sha1:
 9666e1ad1d5edc9b7a09be98e4c554dcc600e445 2691 gpac_0.7.1+dfsg1-3.dsc
 a20e01d9353bf4dfda445647456084f7d0b66f5d 45448 gpac_0.7.1+dfsg1-3.debian.tar.xz
Checksums-Sha256:
 26276b5e08112751122aaad4ae22e826d3552abeb75541450b105e47ef665068 2691 
gpac_0.7.1+dfsg1-3.dsc
 8b7036374d56a9c9f0dfb3e3a757dac301ecc45ef39d331161bff596bedb9d85 45448 
gpac_0.7.1+dfsg1-3.debian.tar.xz
Files:
 a15eb462cc2ce70ca570e33e2aeb528e 2691 graphics optional gpac_0.7.1+dfsg1-3.dsc
 bda1c51a0d0ce0f13287dbbd9e1c6e7e 45448 graphics optional 
gpac_0.7.1+dfsg1-3.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQJIBAEBCgAyFiEEMN59F2OrlFLH4IJQSadpd5QoJssFAlyyTq4UHHNpcmV0YXJ0
QHRhdXdhcmUuZGUACgkQSadpd5QoJssD3Q/+KmZz2HFWLTN/2S1ljlWjCzCuJPt8
+CimxsyDPGoMFR4GElCcEdJK/Xi+poAINYlHARxHGJw5ZtbhG7YppaLO2HfNUBQz
Hng7TxE3jlgj6ExeUnRLiu/gcq2COFn1+j9HmdWA1XmejxW2i6UG7rsGuAgii97L
vqpQJmxAJNWmM+fxVJdpkWed+zUb/iB6byhaBSTzdUVcaotu25GPwSEvWkX+jmMC
Xr2GjqDQA/+BpqCfhA8zCQgRDdErZlvUDYfdXTyO3y20VuR+2xI7fKeJHcYVJACe
BoEiE0oipfXhtElzsns7ufHH4oZobs+3mixTxID1BHiZGKuszB1jCDF+dcOwXE+G
rrENJf8kOje3EHiE9i9DMZHQ0nYclqQXlcZrsAXXOya8H0Z+Gwg9i7bPhxHQYS2J
qJErMrAYBLXrr8TwKN6rNFAk1MPGMNZU7k6p5tzS4AgRuv5lMUlQ2sMRV3RPPsKp
qtbAhnMuu5Ebasn0Ro9Mt3T7LznRvTXQHY9UkyIO9rukCZwnR9Hc5eVkL5DJ483P
uZGzsJj0If8SSg5VZdSunACkWEWw7p97wEmaJSAA+mwunyZDNX0cKv0WrzaCJfDc
Claqf4YgPxtQcklKnq4ZAmDUi5utd+ZBms75oCv06/NH8c2ZKWIpaZVot4bI8jal
sRwe53FHxouMQkg=
=jmyP
-END PGP SIGNATURE-

Accepted gpac 0.5.2-426-gc5ad4e4+dfsg5-5 (source) into unstable

[Reinhard Tartler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 13 Apr 2019 16:41:15 -0400
Source: gpac
Architecture: source
Version: 0.5.2-426-gc5ad4e4+dfsg5-5
Distribution: unstable
Urgency: medium
Maintainer: Debian Multimedia Maintainers 
Changed-By: Reinhard Tartler 
Closes: 926961 926963
Changes:
 gpac (0.5.2-426-gc5ad4e4+dfsg5-5) unstable; urgency=medium
 .
   [ Moritz Muehlenhoff ]
   * Bug fix: "CVE-2019-11222: Buffer-overflow in gf_bin128_parse", thanks
 to Salvatore Bonaccorso (Closes: #926961).
   * Bug fix: "CVE-2019-11221: buffer-overflow issue in gf_import_message()
 in media_import.c", thanks to Salvatore Bonaccorso (Closes: #926963).
Checksums-Sha1:
 87ee388ad9fc8d3602c02b8b52a67ae45786ef69 2707 
gpac_0.5.2-426-gc5ad4e4+dfsg5-5.dsc
 1704c931348d58dba7778007e88569690a7f3afc 43692 
gpac_0.5.2-426-gc5ad4e4+dfsg5-5.debian.tar.xz
Checksums-Sha256:
 8d2584c04673ff9ca9b235d42bb3ce37caaaf71205d4bc1a5ca549bdaae6ed7a 2707 
gpac_0.5.2-426-gc5ad4e4+dfsg5-5.dsc
 a827ba9c1fdc64ef9a04515e306cba8f614eafa2730b83eea3cf6a57cfbfcbd4 43692 
gpac_0.5.2-426-gc5ad4e4+dfsg5-5.debian.tar.xz
Files:
 e8fb23750dea9aed3c8617a85a2d3151 2707 graphics optional 
gpac_0.5.2-426-gc5ad4e4+dfsg5-5.dsc
 5aa9f8ecce5a70745c10638480b2c42c 43692 graphics optional 
gpac_0.5.2-426-gc5ad4e4+dfsg5-5.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQJIBAEBCgAyFiEEMN59F2OrlFLH4IJQSadpd5QoJssFAlyySd4UHHNpcmV0YXJ0
QHRhdXdhcmUuZGUACgkQSadpd5QoJsuLWg//aWCbEl3s1559yhebhhtJj/Hx92fj
KTMiAstjBtig0vX1sGunzI/qK24aHq+90Ld2kWxk9N7IBL2wcl1GkjuyvtSZQOSh
oaD8v9jjtiGBdETNctG5JKsZXQ60RLJUWmDeiV278jfqFjcWD3YV7pQ9jojFaKJG
SBFE4/f22QVnmJDYQAGBzbIqR3PU6+auYDJianPSvL3qEyFI2AXDN3N/wwIWYkk6
c30Ouqm1Wm3YPQFDp/p7I0DQjM0qukIg9AXLvAHWwjxv9IAVj0fWcz/vDlL+Z4IQ
unXWHWFiOXJe8+kVgXuGPvFR+lDqNwlxjiGM4agPyMdpduRfECzAliWKNq6kIZdr
aIIEOid0mdI33IAG045nqfNPBnoP8RJxZ6Td8y/6zXEPzK/GjsGZ/rh01w1XUo8N
ukz9nK55eIAZXt2HcyPP4bVPOYTwUjudCa8VJIUvlpTeJY6Fq+l4/rQy4fvb2Thg
Es+tA6dHy3fNbHM22Mv+GfFlIFZcnACHf79h4nrJF4R3FXGzcbkUynuhi/F/sQaf
2Kt/mgjwENEiTwtcp4LAedaTgA/EslM1MWsFJ+ukKDfYBOLURpIIs2qV5wdzxbXg
0KfMp5OvzjrHnKH/hEK+4V5mlYse098ekctT/Kk1Qv0RndOwSP5UiUmbl73cex85
N+NrCdXrzm7XID8=
=CYuu
-END PGP SIGNATURE-

[pkg-go] Bug#926824: go-md2man: Produced manpages contain many warnings "manpage-has-bad-whatis-entry" lintian warnings

[Reinhard Tartler]

Source: go-md2man
Severity: normal

I'm using this tool in the golang-github-containers-storage. At the end
of the package build, I see lots of warnings like this:

,
| W: containers-storage: manpage-has-bad-whatis-entry 
usr/share/man/man1/containers-storage-mounted.1.gz
| W: containers-storage: manpage-has-bad-whatis-entry 
usr/share/man/man1/containers-storage-set-container-data.1.gz
| W: containers-storage: manpage-has-bad-whatis-entry 
usr/share/man/man1/containers-storage-set-image-data.1.gz
| W: containers-storage: manpage-has-bad-whatis-entry 
usr/share/man/man1/containers-storage-set-metadata.1.gz
| W: containers-storage: manpage-has-bad-whatis-entry 
usr/share/man/man1/containers-storage-set-names.1.gz
| W: containers-storage: manpage-has-bad-whatis-entry 
usr/share/man/man1/containers-storage-shutdown.1.gz
| W: containers-storage: manpage-has-bad-whatis-entry 
usr/share/man/man1/containers-storage-status.1.gz
| W: containers-storage: manpage-has-bad-whatis-entry 
usr/share/man/man1/containers-storage-unmount.1.gz
| W: containers-storage: manpage-has-bad-whatis-entry 
usr/share/man/man1/containers-storage-version.1.gz
| W: containers-storage: manpage-has-bad-whatis-entry 
usr/share/man/man1/containers-storage-wipe.1.gz
`


The description of the lintian warning reads:

,[ lintian-info -t manpage-has-bad-whatis-entry
| W: manpage-has-bad-whatis-entry
| N:
| N:   Each manual page should start with a "NAME" section, which lists the
| N:   name and a brief description of the page separated by "\-". The "NAME"
| N:   section is parsed by lexgrog and used to generate a database that's
| N:   queried by commands like apropos and whatis. This tag indicates that
| N:   lexgrog was unable to parse the NAME section of this manual page.
| N:   
| N:   For manual pages that document multiple programs, functions, files, or
| N:   other things, the part before "\-" should list each separated by a
| N:   comma and a space. Each thing listed must not contain spaces; a man
| N:   page for a two-part command like "fs listacl" must use something like
| N:   "fs_listacl" in the "NAME" section so that it can be parsed by
| N:   lexgrog.
| N:   
| N:   Refer to the lexgrog(1) manual page, the groff_man(7) manual page, and
| N:   the groff_mdoc(7) manual page for details.
| N:   
| N:   Severity: normal, Certainty: certain
| N:   
| N:   Check: manpages, Type: binary
| N:
`

The .md files have headers that look like this:

,
| ## containers-storage-add-names "August 2016"
| 
| ## NAME
| containers-storage add-names - Add names to a layer/image/container
| [...]
`

AFAIUI the generated manpage should produce '\-' instead of '-' to have a 
functional
whatis database and unbreak lexgrog.

Best,
-rt

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#926824: go-md2man: Produced manpages contain many warnings "manpage-has-bad-whatis-entry" lintian warnings

[Reinhard Tartler]

Source: go-md2man
Severity: normal

I'm using this tool in the golang-github-containers-storage. At the end
of the package build, I see lots of warnings like this:

,
| W: containers-storage: manpage-has-bad-whatis-entry 
usr/share/man/man1/containers-storage-mounted.1.gz
| W: containers-storage: manpage-has-bad-whatis-entry 
usr/share/man/man1/containers-storage-set-container-data.1.gz
| W: containers-storage: manpage-has-bad-whatis-entry 
usr/share/man/man1/containers-storage-set-image-data.1.gz
| W: containers-storage: manpage-has-bad-whatis-entry 
usr/share/man/man1/containers-storage-set-metadata.1.gz
| W: containers-storage: manpage-has-bad-whatis-entry 
usr/share/man/man1/containers-storage-set-names.1.gz
| W: containers-storage: manpage-has-bad-whatis-entry 
usr/share/man/man1/containers-storage-shutdown.1.gz
| W: containers-storage: manpage-has-bad-whatis-entry 
usr/share/man/man1/containers-storage-status.1.gz
| W: containers-storage: manpage-has-bad-whatis-entry 
usr/share/man/man1/containers-storage-unmount.1.gz
| W: containers-storage: manpage-has-bad-whatis-entry 
usr/share/man/man1/containers-storage-version.1.gz
| W: containers-storage: manpage-has-bad-whatis-entry 
usr/share/man/man1/containers-storage-wipe.1.gz
`


The description of the lintian warning reads:

,[ lintian-info -t manpage-has-bad-whatis-entry
| W: manpage-has-bad-whatis-entry
| N:
| N:   Each manual page should start with a "NAME" section, which lists the
| N:   name and a brief description of the page separated by "\-". The "NAME"
| N:   section is parsed by lexgrog and used to generate a database that's
| N:   queried by commands like apropos and whatis. This tag indicates that
| N:   lexgrog was unable to parse the NAME section of this manual page.
| N:   
| N:   For manual pages that document multiple programs, functions, files, or
| N:   other things, the part before "\-" should list each separated by a
| N:   comma and a space. Each thing listed must not contain spaces; a man
| N:   page for a two-part command like "fs listacl" must use something like
| N:   "fs_listacl" in the "NAME" section so that it can be parsed by
| N:   lexgrog.
| N:   
| N:   Refer to the lexgrog(1) manual page, the groff_man(7) manual page, and
| N:   the groff_mdoc(7) manual page for details.
| N:   
| N:   Severity: normal, Certainty: certain
| N:   
| N:   Check: manpages, Type: binary
| N:
`

The .md files have headers that look like this:

,
| ## containers-storage-add-names "August 2016"
| 
| ## NAME
| containers-storage add-names - Add names to a layer/image/container
| [...]
`

AFAIUI the generated manpage should produce '\-' instead of '-' to have a 
functional
whatis database and unbreak lexgrog.

Best,
-rt

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#921949: golang-github-containers-storage_1.5-1_amd64.changes REJECTED

[Reinhard Tartler]

Hi Thorsten,

thank you for looking at the package.

On 4/10/19 3:00 PM, Thorsten Alteholz wrote: 
> I don't think that it is ok to add all contributors to your debian/copyright
> although the LICENSE says that Docker, Inc claims the copyright (and they
> are missing).

I don't think this is accurate either. Most if of not all upstream maintainers 
are actually RedHat employees. This may not be obvious from looking at the 
source code.

Would it be acceptable to state "(C) 2013-2019 github.com/containers/storage 
maintainers"?

If neither that rather vague specification (which is used in packages such as 
docker, cf. 
https://tracker.debian.org/media/packages/d/docker.io/copyright-18.09.1dfsg1-5 
and Linux, cf. 
https://tracker.debian.org/media/packages/l/linux/copyright-5.0.2-1exp1, as 
well), nor the authors listed in the AUTHORS file is acceptable, what would you 
recommend me to do?

> While you are at it, please also mention pkg/mflag in your debian/copyright.

Thanks for the hint. In fact, I've already started working on a new upstream 
release and have clarified the pkg/mflag license.

Cheers,
-rt

Bug#921949: golang-github-containers-storage_1.5-1_amd64.changes REJECTED

[Reinhard Tartler]

Hi Thorsten,

thank you for looking at the package.

On 4/10/19 3:00 PM, Thorsten Alteholz wrote: 
> I don't think that it is ok to add all contributors to your debian/copyright
> although the LICENSE says that Docker, Inc claims the copyright (and they
> are missing).

I don't think this is accurate either. Most if of not all upstream maintainers 
are actually RedHat employees. This may not be obvious from looking at the 
source code.

Would it be acceptable to state "(C) 2013-2019 github.com/containers/storage 
maintainers"?

If neither that rather vague specification (which is used in packages such as 
docker, cf. 
https://tracker.debian.org/media/packages/d/docker.io/copyright-18.09.1dfsg1-5 
and Linux, cf. 
https://tracker.debian.org/media/packages/l/linux/copyright-5.0.2-1exp1, as 
well), nor the authors listed in the AUTHORS file is acceptable, what would you 
recommend me to do?

> While you are at it, please also mention pkg/mflag in your debian/copyright.

Thanks for the hint. In fact, I've already started working on a new upstream 
release and have clarified the pkg/mflag license.

Cheers,
-rt

Accepted gpac 0.7.1+dfsg1-2 (amd64 source) into experimental, experimental

[Reinhard Tartler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 07 Apr 2019 12:19:28 -0400
Binary: gpac gpac-dbgsym gpac-modules-base gpac-modules-base-dbgsym libgpac7 
libgpac7-dbgsym libgpac-dev
Source: gpac
Architecture: amd64 source
Version: 0.7.1+dfsg1-2
Distribution: experimental
Urgency: medium
Maintainer: Debian Multimedia Maintainers 
Changed-By: Reinhard Tartler 
Closes: 817194 892526 902782 921969
Description: 
 gpac   - GPAC Project on Advanced Content - utilities
 gpac-modules-base - GPAC Project on Advanced Content - modules
 libgpac7   - GPAC Project on Advanced Content - shared libraries
 libgpac-dev - GPAC Project on Advanced Content - development files
Changes:
 gpac (0.7.1+dfsg1-2) experimental; urgency=medium
 .
   * Upload to experimental and mark the previous upload as
 UNRELEASED. It was deemed unappropriate for this stage of the
 Debian Release cycle.
 .
 gpac (0.7.1+dfsg1-1) UNRELEASED; urgency=medium
 .
   [ Balint Reczey ]
   * Remove myself from Uploaders
 .
   [ Reinhard Tartler ]
   * Update exclude lists
   * New upstream version 0.7.1+dfsg1 (Closes: #817194)
   * Add bugfix for CVE-2018-7752 (Closes: #892526)
   * Add patch for CVE-2018-20760, CVE-2018-20762, CVE-2018-20763
 (CVE-2018-20761 does not need addressing) (Closes: #921969)
   * add patch for CVE-2018-13005, CVE-2018-13006 (Closes: #902782)
Checksums-Sha1: 
 e65e96e8e2426ba46cb2851726c207435f87dc93 2691 gpac_0.7.1+dfsg1-2.dsc
 ca581b816ea4025db5e3ed9e75580ac540ab794b 43900 gpac_0.7.1+dfsg1-2.debian.tar.xz
 f49e6bfbb57a297cdb24202d0185382d6d16b542 498936 
gpac-dbgsym_0.7.1+dfsg1-2_amd64.deb
 31ec99eb1a589c4414e55a8ed93edb229a6ac705 1248996 
gpac-modules-base-dbgsym_0.7.1+dfsg1-2_amd64.deb
 13d6340ce139e151a543f72ba77c37527cf449de 253524 
gpac-modules-base_0.7.1+dfsg1-2_amd64.deb
 ca81efea5c2861f69e87d56e5791f8e989f2a4d4 15759 
gpac_0.7.1+dfsg1-2_amd64.buildinfo
 6c6467a9bb85180daa8b4b20ed7f498a3a60ef9d 240136 gpac_0.7.1+dfsg1-2_amd64.deb
 a102df1ab3e9367dfcae31c89fba22bc3e480141 2185596 
libgpac-dev_0.7.1+dfsg1-2_amd64.deb
 6e5f81e26802c6c00dcf914d7844a5879ac301a6 7027680 
libgpac7-dbgsym_0.7.1+dfsg1-2_amd64.deb
 010c35400b83b449c3af99dc17e0c7f7436815b0 1677884 
libgpac7_0.7.1+dfsg1-2_amd64.deb
Checksums-Sha256: 
 14bbd5732b45338544301b280ae81afdae0572cdfae9ef2ec673d8af4b6e19c4 2691 
gpac_0.7.1+dfsg1-2.dsc
 e22b8157646aee1c33fcfaa0aeca653c38d216f78535c700a0012c842d358f56 43900 
gpac_0.7.1+dfsg1-2.debian.tar.xz
 46fa2a4e80b61ad615e34923973aa97238960b80f2164597faf9ea271a07df2a 498936 
gpac-dbgsym_0.7.1+dfsg1-2_amd64.deb
 4aa494796500030aba065cbee1631eae5a8362f11a25328f28d0027eb19209d7 1248996 
gpac-modules-base-dbgsym_0.7.1+dfsg1-2_amd64.deb
 4209097136859edf0a9bc5ee749cc01d52f6a0f8e8e730a447810c3d88845fdf 253524 
gpac-modules-base_0.7.1+dfsg1-2_amd64.deb
 689755d8faeb14b342cd30e70d755cfc17d873863776e4d589e0b7a51c3ac676 15759 
gpac_0.7.1+dfsg1-2_amd64.buildinfo
 c3eb44dd84635721fbf9efb533b6586efe8ed08e05674f8823869e5d4d8ec330 240136 
gpac_0.7.1+dfsg1-2_amd64.deb
 633d414edd066d6334ef5fd315815c6f6026a358b35fcc3a4cb793ccb94a134e 2185596 
libgpac-dev_0.7.1+dfsg1-2_amd64.deb
 d28b9859c020c188b8b9abb640bb3429d0aaec57524e2e4e089c82340c17f397 7027680 
libgpac7-dbgsym_0.7.1+dfsg1-2_amd64.deb
 cce872e72bbd99961d3c5381ff8cf0ecdd63c147e0407535283ffc77a95b1d02 1677884 
libgpac7_0.7.1+dfsg1-2_amd64.deb
Files: 
 2c6d902a528a5a4021bed068cacefe6a 2691 graphics optional gpac_0.7.1+dfsg1-2.dsc
 71f8ce2998bfc9fa4ee2bb87b0a6e117 43900 graphics optional 
gpac_0.7.1+dfsg1-2.debian.tar.xz
 e01a91af3122744c44dd07179c9be0e7 498936 debug optional 
gpac-dbgsym_0.7.1+dfsg1-2_amd64.deb
 ef33ee2fbf4386275db02b316afed93e 1248996 debug optional 
gpac-modules-base-dbgsym_0.7.1+dfsg1-2_amd64.deb
 6d124dc8bb3aab81830db61819e58679 253524 graphics optional 
gpac-modules-base_0.7.1+dfsg1-2_amd64.deb
 db5949d662ecc8c2bab25733ec1ea295 15759 graphics optional 
gpac_0.7.1+dfsg1-2_amd64.buildinfo
 6908e19c506decb1845482585338 240136 graphics optional 
gpac_0.7.1+dfsg1-2_amd64.deb
 7d0876610d426193d3a61814febdab7e 2185596 libdevel optional 
libgpac-dev_0.7.1+dfsg1-2_amd64.deb
 a122a3e4407f5677fb11691164082e3b 7027680 debug optional 
libgpac7-dbgsym_0.7.1+dfsg1-2_amd64.deb
 7dd36341e6a2e5c8ccc630d399ff8bce 1677884 libs optional 
libgpac7_0.7.1+dfsg1-2_amd64.deb

-BEGIN PGP SIGNATURE-

iQJIBAEBCAAyFiEE6n5rckvJ+/LRcetya3IL6cXPbZ4FAlyqNLsUHHNpcmV0YXJ0
QHRhdXdhcmUuZGUACgkQa3IL6cXPbZ6j5BAAiwpjxQrpidwlVfSOcg47BMwQQloy
8RksT93kJgroY3IyPL0zJlc19U32o7sD6+n7XJ04Z0gT4RqRXhBUnTP4OF33c3Cz
XVf+jSbUm69ax8/03izb2c54ceGlxDj6qe15gPZzVptFl0ZCP+O5oCj3XCBwu9OB
UigY6ZM1YX28c0dW5H2qAxDVJEPjWDXlo8LykzdvTmFDrGbtkAeSRD5/u+FGpAgJ
MXkfHh9WxPrqkk1pE6UsrEZ5zd4qbQP7KjlH+YygGFL4vnc+an6F2NjCET3UTSWj
uDM7AQNkiKf87MBj16vJbc88hPYEiLoROgtfP1RugsN2RZsBsKysjFn8D/FSPqBx
gtaCTEqLvoahPAM5a+/IpTTcODysI6D0GweqTeIX2+FqutsICmZJ6hHQlFVTlZM2
IvsEkMZyRO4n6KMAgTsiI4ddIGCCIFWcrBrII0BTDtjbqkWrgCXEFNGmIBDilqRK
uBY0OFgSMXpfII1uf64qO0UyTvnwplmqs2t08e5lj16RElSsY333z8tzhxIyKaw

Accepted gpac 0.7.1+dfsg1-2 (amd64 source) into experimental, experimental

[Reinhard Tartler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 07 Apr 2019 12:19:28 -0400
Binary: gpac gpac-dbgsym gpac-modules-base gpac-modules-base-dbgsym libgpac7 
libgpac7-dbgsym libgpac-dev
Source: gpac
Architecture: amd64 source
Version: 0.7.1+dfsg1-2
Distribution: experimental
Urgency: medium
Maintainer: Debian Multimedia Maintainers 
Changed-By: Reinhard Tartler 
Closes: 817194 892526 902782 921969
Description: 
 gpac   - GPAC Project on Advanced Content - utilities
 gpac-modules-base - GPAC Project on Advanced Content - modules
 libgpac7   - GPAC Project on Advanced Content - shared libraries
 libgpac-dev - GPAC Project on Advanced Content - development files
Changes:
 gpac (0.7.1+dfsg1-2) experimental; urgency=medium
 .
   * Upload to experimental and mark the previous upload as
 UNRELEASED. It was deemed unappropriate for this stage of the
 Debian Release cycle.
 .
 gpac (0.7.1+dfsg1-1) UNRELEASED; urgency=medium
 .
   [ Balint Reczey ]
   * Remove myself from Uploaders
 .
   [ Reinhard Tartler ]
   * Update exclude lists
   * New upstream version 0.7.1+dfsg1 (Closes: #817194)
   * Add bugfix for CVE-2018-7752 (Closes: #892526)
   * Add patch for CVE-2018-20760, CVE-2018-20762, CVE-2018-20763
 (CVE-2018-20761 does not need addressing) (Closes: #921969)
   * add patch for CVE-2018-13005, CVE-2018-13006 (Closes: #902782)
Checksums-Sha1: 
 e65e96e8e2426ba46cb2851726c207435f87dc93 2691 gpac_0.7.1+dfsg1-2.dsc
 ca581b816ea4025db5e3ed9e75580ac540ab794b 43900 gpac_0.7.1+dfsg1-2.debian.tar.xz
 f49e6bfbb57a297cdb24202d0185382d6d16b542 498936 
gpac-dbgsym_0.7.1+dfsg1-2_amd64.deb
 31ec99eb1a589c4414e55a8ed93edb229a6ac705 1248996 
gpac-modules-base-dbgsym_0.7.1+dfsg1-2_amd64.deb
 13d6340ce139e151a543f72ba77c37527cf449de 253524 
gpac-modules-base_0.7.1+dfsg1-2_amd64.deb
 ca81efea5c2861f69e87d56e5791f8e989f2a4d4 15759 
gpac_0.7.1+dfsg1-2_amd64.buildinfo
 6c6467a9bb85180daa8b4b20ed7f498a3a60ef9d 240136 gpac_0.7.1+dfsg1-2_amd64.deb
 a102df1ab3e9367dfcae31c89fba22bc3e480141 2185596 
libgpac-dev_0.7.1+dfsg1-2_amd64.deb
 6e5f81e26802c6c00dcf914d7844a5879ac301a6 7027680 
libgpac7-dbgsym_0.7.1+dfsg1-2_amd64.deb
 010c35400b83b449c3af99dc17e0c7f7436815b0 1677884 
libgpac7_0.7.1+dfsg1-2_amd64.deb
Checksums-Sha256: 
 14bbd5732b45338544301b280ae81afdae0572cdfae9ef2ec673d8af4b6e19c4 2691 
gpac_0.7.1+dfsg1-2.dsc
 e22b8157646aee1c33fcfaa0aeca653c38d216f78535c700a0012c842d358f56 43900 
gpac_0.7.1+dfsg1-2.debian.tar.xz
 46fa2a4e80b61ad615e34923973aa97238960b80f2164597faf9ea271a07df2a 498936 
gpac-dbgsym_0.7.1+dfsg1-2_amd64.deb
 4aa494796500030aba065cbee1631eae5a8362f11a25328f28d0027eb19209d7 1248996 
gpac-modules-base-dbgsym_0.7.1+dfsg1-2_amd64.deb
 4209097136859edf0a9bc5ee749cc01d52f6a0f8e8e730a447810c3d88845fdf 253524 
gpac-modules-base_0.7.1+dfsg1-2_amd64.deb
 689755d8faeb14b342cd30e70d755cfc17d873863776e4d589e0b7a51c3ac676 15759 
gpac_0.7.1+dfsg1-2_amd64.buildinfo
 c3eb44dd84635721fbf9efb533b6586efe8ed08e05674f8823869e5d4d8ec330 240136 
gpac_0.7.1+dfsg1-2_amd64.deb
 633d414edd066d6334ef5fd315815c6f6026a358b35fcc3a4cb793ccb94a134e 2185596 
libgpac-dev_0.7.1+dfsg1-2_amd64.deb
 d28b9859c020c188b8b9abb640bb3429d0aaec57524e2e4e089c82340c17f397 7027680 
libgpac7-dbgsym_0.7.1+dfsg1-2_amd64.deb
 cce872e72bbd99961d3c5381ff8cf0ecdd63c147e0407535283ffc77a95b1d02 1677884 
libgpac7_0.7.1+dfsg1-2_amd64.deb
Files: 
 2c6d902a528a5a4021bed068cacefe6a 2691 graphics optional gpac_0.7.1+dfsg1-2.dsc
 71f8ce2998bfc9fa4ee2bb87b0a6e117 43900 graphics optional 
gpac_0.7.1+dfsg1-2.debian.tar.xz
 e01a91af3122744c44dd07179c9be0e7 498936 debug optional 
gpac-dbgsym_0.7.1+dfsg1-2_amd64.deb
 ef33ee2fbf4386275db02b316afed93e 1248996 debug optional 
gpac-modules-base-dbgsym_0.7.1+dfsg1-2_amd64.deb
 6d124dc8bb3aab81830db61819e58679 253524 graphics optional 
gpac-modules-base_0.7.1+dfsg1-2_amd64.deb
 db5949d662ecc8c2bab25733ec1ea295 15759 graphics optional 
gpac_0.7.1+dfsg1-2_amd64.buildinfo
 6908e19c506decb1845482585338 240136 graphics optional 
gpac_0.7.1+dfsg1-2_amd64.deb
 7d0876610d426193d3a61814febdab7e 2185596 libdevel optional 
libgpac-dev_0.7.1+dfsg1-2_amd64.deb
 a122a3e4407f5677fb11691164082e3b 7027680 debug optional 
libgpac7-dbgsym_0.7.1+dfsg1-2_amd64.deb
 7dd36341e6a2e5c8ccc630d399ff8bce 1677884 libs optional 
libgpac7_0.7.1+dfsg1-2_amd64.deb

-BEGIN PGP SIGNATURE-

iQJIBAEBCAAyFiEE6n5rckvJ+/LRcetya3IL6cXPbZ4FAlyqNLsUHHNpcmV0YXJ0
QHRhdXdhcmUuZGUACgkQa3IL6cXPbZ6j5BAAiwpjxQrpidwlVfSOcg47BMwQQloy
8RksT93kJgroY3IyPL0zJlc19U32o7sD6+n7XJ04Z0gT4RqRXhBUnTP4OF33c3Cz
XVf+jSbUm69ax8/03izb2c54ceGlxDj6qe15gPZzVptFl0ZCP+O5oCj3XCBwu9OB
UigY6ZM1YX28c0dW5H2qAxDVJEPjWDXlo8LykzdvTmFDrGbtkAeSRD5/u+FGpAgJ
MXkfHh9WxPrqkk1pE6UsrEZ5zd4qbQP7KjlH+YygGFL4vnc+an6F2NjCET3UTSWj
uDM7AQNkiKf87MBj16vJbc88hPYEiLoROgtfP1RugsN2RZsBsKysjFn8D/FSPqBx
gtaCTEqLvoahPAM5a+/IpTTcODysI6D0GweqTeIX2+FqutsICmZJ6hHQlFVTlZM2
IvsEkMZyRO4n6KMAgTsiI4ddIGCCIFWcrBrII0BTDtjbqkWrgCXEFNGmIBDilqRK
uBY0OFgSMXpfII1uf64qO0UyTvnwplmqs2t08e5lj16RElSsY333z8tzhxIyKaw

Accepted golang-github-vbauerster-mpb 3.3.4-1 (source all) into unstable, unstable

[Reinhard Tartler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 20 Mar 2019 17:58:37 -0400
Source: golang-github-vbauerster-mpb
Binary: golang-github-vbauerster-mpb-dev
Architecture: source all
Version: 3.3.4-1
Distribution: unstable
Urgency: medium
Maintainer: Reinhard Tartler 
Changed-By: Reinhard Tartler 
Description:
 golang-github-vbauerster-mpb-dev - multi progress bar for Go cli applications
Closes: 925184
Changes:
 golang-github-vbauerster-mpb (3.3.4-1) unstable; urgency=medium
 .
   * Initial release (Closes: #925184)
Checksums-Sha1:
 03c22dcf0a0ff53475fb4ca3285df1f583f9decd 2357 
golang-github-vbauerster-mpb_3.3.4-1.dsc
 3a10a4bdefa0f934698621fb5857bb7aaa86634b 36460 
golang-github-vbauerster-mpb_3.3.4.orig.tar.xz
 513ab2629832094c338c6ed01bd619c5177f0ded 2516 
golang-github-vbauerster-mpb_3.3.4-1.debian.tar.xz
 ff0ff8afdd14b17b0e122a8cd17ba28a3c7d1c84 26584 
golang-github-vbauerster-mpb-dev_3.3.4-1_all.deb
 e9c54c99f637f7c0b222e818c392d9e50a846b88 6607 
golang-github-vbauerster-mpb_3.3.4-1_amd64.buildinfo
Checksums-Sha256:
 06ea53b396273c4af8186bcd4437daa5d3dc95ceffdef8ebef4cb4d6fe8c2fc1 2357 
golang-github-vbauerster-mpb_3.3.4-1.dsc
 c45f29b847561d22ab0d3503ab1ee419e8dcf5376902f317cd22f8988f23ee49 36460 
golang-github-vbauerster-mpb_3.3.4.orig.tar.xz
 5094ced0758945629e86c9d58ef7a8506012faa89eb66bc4ab008f8aa26541e2 2516 
golang-github-vbauerster-mpb_3.3.4-1.debian.tar.xz
 c2c6bffd8805e6779379baf5f32b855cfc253266868d568ae90ca572c0e876e7 26584 
golang-github-vbauerster-mpb-dev_3.3.4-1_all.deb
 6de432a5ded44f2e21d0e3e0421afc12c28b459cc128b2db2541c769862ba2f8 6607 
golang-github-vbauerster-mpb_3.3.4-1_amd64.buildinfo
Files:
 9275a51c11ecb1479c464453063270da 2357 devel optional 
golang-github-vbauerster-mpb_3.3.4-1.dsc
 249fa2c6a1332fd47850a34ce10ce969 36460 devel optional 
golang-github-vbauerster-mpb_3.3.4.orig.tar.xz
 ec022e5a3077a00ed7da46ae0a05ded6 2516 devel optional 
golang-github-vbauerster-mpb_3.3.4-1.debian.tar.xz
 15aeab45806cbb09e475fbfac3bd37d3 26584 devel optional 
golang-github-vbauerster-mpb-dev_3.3.4-1_all.deb
 e57d870d7899c217ca77b4d813314a22 6607 devel optional 
golang-github-vbauerster-mpb_3.3.4-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJIBAEBCgAyFiEEMN59F2OrlFLH4IJQSadpd5QoJssFAlySuPYUHHNpcmV0YXJ0
QHRhdXdhcmUuZGUACgkQSadpd5QoJsu+nw/+MVQZ+7HWzQCRBaCxi0xkpHSdvXT/
SbeiRhcL+rc+7X4xbP0/VoE5ypZ3H2BhQRZJK4TeILYjMJgZO4BF/Ezmdl0gU8CR
oBRzglrmMICTTMFCLrQC3NLj8j61V2mWZVxu7Glpca7FmB3oObT8BAoU0++6gv49
2Y/4qGjGgkx2t2RceQ3y0hmf0elJQc46SpLXPWZ8ICxbfvRSTbuChG6f8hKX9Efg
m9CvA6rsI9JNRhyHW3JZVwnaGlKURp1/58trS+MM3IvfqLoLDjVIXtBzjxfUdpt6
phOZuPbDgQ4bTe2j6HagJdyWPazH/Hh64SCBY41LkhVilhZ/jwxd0sz72HNPwv39
NqJPMfw5ouVdbVhtSqrGAlEuL2TTHXkRRuUXH2u9/8wQzED5Z1Jd9QDbskP+/VKP
Yx24436W28jc7ij0pzSfEuyTQlFU4oRzZifRkspG2OVM0/qQCa/y8ZfzO39lkwYl
O7MiY5rHKd1KlSmPDyvZ71HITxy7qFK7L0G99ZxoAEaz1lcCpz61Lu6uvMe7zu6/
ZDo7Vza1ha88dnij6diBVp8GBvAIYE3oBGDDlb7mHwJq0kB6crVu2UfrjUwq0EOZ
oPN1rVeZ8mEuvAO7Gb1bbMIdNPJjffqQ1D5GzkrzCmexm0tOhVvJSFb8wbLKjE1j
ShxQkK/h114QgVI=
=17Uh
-END PGP SIGNATURE-

Re: gpac_0.7.1+dfsg1-1_amd64.changes is NEW

[Reinhard Tartler]

[trimming receipients]

On Wed, Apr 10, 2019 at 3:44 AM Emilio Pozuelo Monfort 
wrote:

> > Uploaded 0.7.1-2 to experimental, which is (again) in NEW. Thorsten,
> > let me know if there are any issues with that upload.
>
> 0.7.1-1 is still in NEW targetting unstable, so if -2 gets accepted, -1
> will end
> up in unstable. Thus this needs to be rejected, and then reuploaded
> (whether as
> -1 or something else).
>

Makes sense to me. Thorsten, please proceed with rejecting -1, I'm happy to
reupload as -1 to experimental.

Best,
-rt


-- 
regards,
Reinhard

Bug#926704: unblock: pcsc-cyberjack/3.99.5final.sp09-2

[Reinhard Tartler]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package pcsc-cyberjack

As explained in
http://lists.debian.org/4e3fbda7-abe1-b106-b191-67a49c47d...@tauware.de, Frank
and I would love to see #926103 fixed for Debian 9. Please unblock this new
package that I just uploaded to unstable.

unblock pcsc-cyberjack/3.99.5final.sp09-2

For your reviewing convenience, I've included the full debdiff at the end of
this email.

Thank you in advance!
-rt


diff -Nru pcsc-cyberjack-3.99.5final.sp09/debian/changelog 
pcsc-cyberjack-3.99.5final.sp09/debian/changelog
--- pcsc-cyberjack-3.99.5final.sp09/debian/changelog2017-05-29 
14:33:13.0 -0400
+++ pcsc-cyberjack-3.99.5final.sp09/debian/changelog2019-04-08 
17:58:31.0 -0400
@@ -1,3 +1,11 @@
+pcsc-cyberjack (3.99.5final.sp09-2) unstable; urgency=medium
+
+  * Acknowledge NMU.
+  * Bug fix: "driver breaks with pcsc-lite versions >= 1.8.21", thanks
+to Peter Wienemann (Closes: #926103).
+
+ -- Reinhard Tartler   Mon, 08 Apr 2019 17:58:31 -0400
+
 pcsc-cyberjack (3.99.5final.sp09-1.1) unstable; urgency=medium

   * Non-maintainer upload.
diff -Nru pcsc-cyberjack-3.99.5final.sp09/debian/patches/series 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/series
--- pcsc-cyberjack-3.99.5final.sp09/debian/patches/series   2017-05-29 
14:33:11.0 -0400
+++ pcsc-cyberjack-3.99.5final.sp09/debian/patches/series   2019-04-08 
17:58:31.0 -0400
@@ -1 +1,2 @@
 enable_pinpad_ecom.patch
+work-with-newer-pcsc-lite.patch
diff -Nru 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch
--- 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch  
1969-12-31 19:00:00.0 -0500
+++ 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch  
2019-04-08 17:58:31.0 -0400
@@ -0,0 +1,58 @@
+commit 8ab61acfa0a8efc3c65098d4c621d761b7e05da1
+Author: Frank Neuber 
+Date:   Fri Apr 27 11:09:24 2018 +0200
+
+correct the large buffer problem with newer versions of pcscd
+
+--- a/cjeca32/EC30Reader.cpp
 b/cjeca32/EC30Reader.cpp
+@@ -162,21 +162,23 @@ CJ_RESULT CEC30Reader::CtApplicationData
+ {
+int Res;
+   uint32_t Len;
+-  uint16_t wLenRsp=0;
+-  uint16_t wLenErr=0;
++  uint32_t wLenRsp=0;
++  uint32_t wLenErr=0;
+   if(ResponseLen!=0)
+-  wLenRsp=(uint16_t)*ResponseLen;
++  wLenRsp=*ResponseLen;
+   if(ApplicationErrorLength!=NULL)
+-  wLenErr=(uint16_t)*ApplicationErrorLength;
+-  if(m_nApplicationResponseLength<(uint32_t)wLenRsp+wLenErr+4)
++  wLenErr=*ApplicationErrorLength;
++  Len=4+wLenRsp+wLenErr;
++  if(m_nApplicationResponseLength0xFFFB) // overflow or bigger than 0x - 4
++  return CJ_ERR_WRONG_PARAMETER;
+
+   
if((Res=Escape(ApplicationID,Function,InputData,InputLen,Result,m_pApplicationResponse,,Slot)))
+   {
+@@ -186,10 +188,14 @@ CJ_RESULT CEC30Reader::CtApplicationData
+   *ApplicationErrorLength=0;
+   return Res;
+   }
+-  memcpy(,m_pApplicationResponse,sizeof(wLenRsp));
+-  wLenRsp=ReaderToHostShort(wLenRsp);
+-  memcpy(,m_pApplicationResponse+2,sizeof(wLenErr));
+-  wLenErr=ReaderToHostShort(wLenErr);
++
++  uint16_t wLenRsp16 = 0;
++  uint16_t wLenErr16 = 0;
++  memcpy(,m_pApplicationResponse,sizeof(wLenRsp16));
++  wLenRsp=ReaderToHostShort(wLenRsp16);
++  memcpy(,m_pApplicationResponse+2,sizeof(wLenErr16));
++  wLenErr=ReaderToHostShort(wLenErr16);
++
+   if(ApplicationErrorLength)
+   {
+   if(wLenErr>*ApplicationErrorLength)



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#926704: unblock: pcsc-cyberjack/3.99.5final.sp09-2

[Reinhard Tartler]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package pcsc-cyberjack

As explained in
http://lists.debian.org/4e3fbda7-abe1-b106-b191-67a49c47d...@tauware.de, Frank
and I would love to see #926103 fixed for Debian 9. Please unblock this new
package that I just uploaded to unstable.

unblock pcsc-cyberjack/3.99.5final.sp09-2

For your reviewing convenience, I've included the full debdiff at the end of
this email.

Thank you in advance!
-rt


diff -Nru pcsc-cyberjack-3.99.5final.sp09/debian/changelog 
pcsc-cyberjack-3.99.5final.sp09/debian/changelog
--- pcsc-cyberjack-3.99.5final.sp09/debian/changelog2017-05-29 
14:33:13.0 -0400
+++ pcsc-cyberjack-3.99.5final.sp09/debian/changelog2019-04-08 
17:58:31.0 -0400
@@ -1,3 +1,11 @@
+pcsc-cyberjack (3.99.5final.sp09-2) unstable; urgency=medium
+
+  * Acknowledge NMU.
+  * Bug fix: "driver breaks with pcsc-lite versions >= 1.8.21", thanks
+to Peter Wienemann (Closes: #926103).
+
+ -- Reinhard Tartler   Mon, 08 Apr 2019 17:58:31 -0400
+
 pcsc-cyberjack (3.99.5final.sp09-1.1) unstable; urgency=medium

   * Non-maintainer upload.
diff -Nru pcsc-cyberjack-3.99.5final.sp09/debian/patches/series 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/series
--- pcsc-cyberjack-3.99.5final.sp09/debian/patches/series   2017-05-29 
14:33:11.0 -0400
+++ pcsc-cyberjack-3.99.5final.sp09/debian/patches/series   2019-04-08 
17:58:31.0 -0400
@@ -1 +1,2 @@
 enable_pinpad_ecom.patch
+work-with-newer-pcsc-lite.patch
diff -Nru 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch
--- 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch  
1969-12-31 19:00:00.0 -0500
+++ 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch  
2019-04-08 17:58:31.0 -0400
@@ -0,0 +1,58 @@
+commit 8ab61acfa0a8efc3c65098d4c621d761b7e05da1
+Author: Frank Neuber 
+Date:   Fri Apr 27 11:09:24 2018 +0200
+
+correct the large buffer problem with newer versions of pcscd
+
+--- a/cjeca32/EC30Reader.cpp
 b/cjeca32/EC30Reader.cpp
+@@ -162,21 +162,23 @@ CJ_RESULT CEC30Reader::CtApplicationData
+ {
+int Res;
+   uint32_t Len;
+-  uint16_t wLenRsp=0;
+-  uint16_t wLenErr=0;
++  uint32_t wLenRsp=0;
++  uint32_t wLenErr=0;
+   if(ResponseLen!=0)
+-  wLenRsp=(uint16_t)*ResponseLen;
++  wLenRsp=*ResponseLen;
+   if(ApplicationErrorLength!=NULL)
+-  wLenErr=(uint16_t)*ApplicationErrorLength;
+-  if(m_nApplicationResponseLength<(uint32_t)wLenRsp+wLenErr+4)
++  wLenErr=*ApplicationErrorLength;
++  Len=4+wLenRsp+wLenErr;
++  if(m_nApplicationResponseLength0xFFFB) // overflow or bigger than 0x - 4
++  return CJ_ERR_WRONG_PARAMETER;
+
+   
if((Res=Escape(ApplicationID,Function,InputData,InputLen,Result,m_pApplicationResponse,,Slot)))
+   {
+@@ -186,10 +188,14 @@ CJ_RESULT CEC30Reader::CtApplicationData
+   *ApplicationErrorLength=0;
+   return Res;
+   }
+-  memcpy(,m_pApplicationResponse,sizeof(wLenRsp));
+-  wLenRsp=ReaderToHostShort(wLenRsp);
+-  memcpy(,m_pApplicationResponse+2,sizeof(wLenErr));
+-  wLenErr=ReaderToHostShort(wLenErr);
++
++  uint16_t wLenRsp16 = 0;
++  uint16_t wLenErr16 = 0;
++  memcpy(,m_pApplicationResponse,sizeof(wLenRsp16));
++  wLenRsp=ReaderToHostShort(wLenRsp16);
++  memcpy(,m_pApplicationResponse+2,sizeof(wLenErr16));
++  wLenErr=ReaderToHostShort(wLenErr16);
++
+   if(ApplicationErrorLength)
+   {
+   if(wLenErr>*ApplicationErrorLength)



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Accepted pcsc-cyberjack 3.99.5final.sp09-2 (source) into unstable

[Reinhard Tartler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 08 Apr 2019 17:58:31 -0400
Source: pcsc-cyberjack
Architecture: source
Version: 3.99.5final.sp09-2
Distribution: unstable
Urgency: medium
Maintainer: Frank Neuber 
Changed-By: Reinhard Tartler 
Closes: 926103
Changes:
 pcsc-cyberjack (3.99.5final.sp09-2) unstable; urgency=medium
 .
   * Acknoledge NMU.
   * Bug fix: "driver breaks with pcsc-lite versions >= 1.8.21", thanks
 to Peter Wienemann (Closes: #926103).
Checksums-Sha1:
 5cebc00d9fac32d0dbf4df59025195a3f3e9b9c5 2289 
pcsc-cyberjack_3.99.5final.sp09-2.dsc
 0fb1beefd7b1ce0b46d6d283514c5f5ef2702740 4820 
pcsc-cyberjack_3.99.5final.sp09-2.debian.tar.xz
Checksums-Sha256:
 e03c12ea3de390aae525a6bf3e962d4846eb3f773133e9e2a02ebaf086ef4081 2289 
pcsc-cyberjack_3.99.5final.sp09-2.dsc
 d5a11f4148093e97129189be0fecde26efe7086f74816a5935199fdfdfc20f92 4820 
pcsc-cyberjack_3.99.5final.sp09-2.debian.tar.xz
Files:
 454845db20868edcc16010b58f1dc573 2289 misc optional 
pcsc-cyberjack_3.99.5final.sp09-2.dsc
 e4ee699da0a995427122d5c939e1b6e4 4820 misc optional 
pcsc-cyberjack_3.99.5final.sp09-2.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQJIBAEBCgAyFiEEMN59F2OrlFLH4IJQSadpd5QoJssFAlyse6sUHHNpcmV0YXJ0
QHRhdXdhcmUuZGUACgkQSadpd5QoJssnKA/9GY7RmYHJHEyeDrTLFeyGRQut18QX
oBqUb9h5H+QJ34tSpapbfcbT/8SCrrDgS2o2klSY3c77Y1FY3t9vb7gvH1ThVCVM
4Q7QX4t8vll2RqexFdzbFTckovJ1arvaJbiSA+CqQt3hE1s3p43biG+YBu4NlSne
GrgRcQQ4yJBDGY/68EQCEfd++tC7LLDRFuinOqMGgfQzIOymyefHd9WaJnpBbUOF
TiiF8p3qkIWkdRjJTuRn/mdigHYQeqvd0OqugoiGrA7hG/CnhJyg+wMH2ffcVCSc
ln92vO9SIPs9dy/q2p/5CUEtCKuBFt+HgkpO/9wQ8X7QSgzKPYgwAlATmjIQGQEv
0xXj3W84M2FXb357AJ1ZrWx3pUl1WIUewlKaJGZDjitYPAhyIEKSjz4nkgzdE6MI
qBUuHTy/dhwht7JJCTmLQy3KwPZNYomKksT56pJbOpGpWmw8aRx4OHLRGkLNQqaz
6JvVFrGaXa8QCh0qJzbIhHAZWegYiR46wrHYWG0liVL/WrcubDFaZlcxDnob5vYh
cQCS2KxVOGXc6iK9/Gxn1rFVUtk4HqRqnA68U3F5SDikmaJbpw0RRWpawJXgSNR5
lxpF3BFqc/BaiLwjsvt9SkrA5EHNZUdFMAfbPVcd5NnBleMcpSqhkkXdpbfu03m3
XPsC9NTNJgpAx7o=
=eM1+
-END PGP SIGNATURE-

Freeze-exception for pcsc-cyberjack 3.99.5final.sp09-2

[Reinhard Tartler]

Hi Release Team,

Frank and I would like to see RC bug #926103 fixed in Debian 10. Please approve 
the attached debdiff, so that I can upload the fixed package to unstable.

Thank you for your consideration.

Best,
Reinhard
diff -Nru pcsc-cyberjack-3.99.5final.sp09/debian/changelog 
pcsc-cyberjack-3.99.5final.sp09/debian/changelog
--- pcsc-cyberjack-3.99.5final.sp09/debian/changelog2017-05-29 
14:33:13.0 -0400
+++ pcsc-cyberjack-3.99.5final.sp09/debian/changelog2019-04-08 
17:58:31.0 -0400
@@ -1,3 +1,11 @@
+pcsc-cyberjack (3.99.5final.sp09-2) unstable; urgency=medium
+
+  * Acknoledge NMU.
+  * Bug fix: "driver breaks with pcsc-lite versions >= 1.8.21", thanks
+to Peter Wienemann (Closes: #926103).
+
+ -- Reinhard Tartler   Mon, 08 Apr 2019 17:58:31 -0400
+
 pcsc-cyberjack (3.99.5final.sp09-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru pcsc-cyberjack-3.99.5final.sp09/debian/patches/series 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/series
--- pcsc-cyberjack-3.99.5final.sp09/debian/patches/series   2017-05-29 
14:33:11.0 -0400
+++ pcsc-cyberjack-3.99.5final.sp09/debian/patches/series   2019-04-08 
17:58:31.0 -0400
@@ -1 +1,2 @@
 enable_pinpad_ecom.patch
+work-with-newer-pcsc-lite.patch
diff -Nru 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch
--- 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch  
1969-12-31 19:00:00.0 -0500
+++ 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch  
2019-04-08 17:58:31.0 -0400
@@ -0,0 +1,58 @@
+commit 8ab61acfa0a8efc3c65098d4c621d761b7e05da1
+Author: Frank Neuber 
+Date:   Fri Apr 27 11:09:24 2018 +0200
+
+correct the large buffer problem with newer versions of pcscd
+
+--- a/cjeca32/EC30Reader.cpp
 b/cjeca32/EC30Reader.cpp
+@@ -162,21 +162,23 @@ CJ_RESULT CEC30Reader::CtApplicationData
+ {
+int Res;
+   uint32_t Len;
+-  uint16_t wLenRsp=0;
+-  uint16_t wLenErr=0;
++  uint32_t wLenRsp=0;
++  uint32_t wLenErr=0;
+   if(ResponseLen!=0)
+-  wLenRsp=(uint16_t)*ResponseLen;
++  wLenRsp=*ResponseLen;
+   if(ApplicationErrorLength!=NULL)
+-  wLenErr=(uint16_t)*ApplicationErrorLength;
+-  if(m_nApplicationResponseLength<(uint32_t)wLenRsp+wLenErr+4)
++  wLenErr=*ApplicationErrorLength;
++  Len=4+wLenRsp+wLenErr;
++  if(m_nApplicationResponseLength0xFFFB) // overflow or bigger than 0x - 4
++  return CJ_ERR_WRONG_PARAMETER;
+ 
+   
if((Res=Escape(ApplicationID,Function,InputData,InputLen,Result,m_pApplicationResponse,,Slot)))
+   {
+@@ -186,10 +188,14 @@ CJ_RESULT CEC30Reader::CtApplicationData
+   *ApplicationErrorLength=0;
+   return Res;
+   }
+-  memcpy(,m_pApplicationResponse,sizeof(wLenRsp));
+-  wLenRsp=ReaderToHostShort(wLenRsp);
+-  memcpy(,m_pApplicationResponse+2,sizeof(wLenErr));
+-  wLenErr=ReaderToHostShort(wLenErr);
++
++  uint16_t wLenRsp16 = 0;
++  uint16_t wLenErr16 = 0;
++  memcpy(,m_pApplicationResponse,sizeof(wLenRsp16));
++  wLenRsp=ReaderToHostShort(wLenRsp16);
++  memcpy(,m_pApplicationResponse+2,sizeof(wLenErr16));
++  wLenErr=ReaderToHostShort(wLenErr16);
++
+   if(ApplicationErrorLength)
+   {
+   if(wLenErr>*ApplicationErrorLength)

Bug#926103: Freeze-exception for pcsc-cyberjack 3.99.5final.sp09-2

[Reinhard Tartler]

Hi Release Team,

Frank and I would like to see RC bug #926103 fixed in Debian 10. Please approve 
the attached debdiff, so that I can upload the fixed package to unstable.

Thank you for your consideration.

Best,
Reinhard
diff -Nru pcsc-cyberjack-3.99.5final.sp09/debian/changelog 
pcsc-cyberjack-3.99.5final.sp09/debian/changelog
--- pcsc-cyberjack-3.99.5final.sp09/debian/changelog2017-05-29 
14:33:13.0 -0400
+++ pcsc-cyberjack-3.99.5final.sp09/debian/changelog2019-04-08 
17:58:31.0 -0400
@@ -1,3 +1,11 @@
+pcsc-cyberjack (3.99.5final.sp09-2) unstable; urgency=medium
+
+  * Acknoledge NMU.
+  * Bug fix: "driver breaks with pcsc-lite versions >= 1.8.21", thanks
+to Peter Wienemann (Closes: #926103).
+
+ -- Reinhard Tartler   Mon, 08 Apr 2019 17:58:31 -0400
+
 pcsc-cyberjack (3.99.5final.sp09-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru pcsc-cyberjack-3.99.5final.sp09/debian/patches/series 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/series
--- pcsc-cyberjack-3.99.5final.sp09/debian/patches/series   2017-05-29 
14:33:11.0 -0400
+++ pcsc-cyberjack-3.99.5final.sp09/debian/patches/series   2019-04-08 
17:58:31.0 -0400
@@ -1 +1,2 @@
 enable_pinpad_ecom.patch
+work-with-newer-pcsc-lite.patch
diff -Nru 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch
--- 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch  
1969-12-31 19:00:00.0 -0500
+++ 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch  
2019-04-08 17:58:31.0 -0400
@@ -0,0 +1,58 @@
+commit 8ab61acfa0a8efc3c65098d4c621d761b7e05da1
+Author: Frank Neuber 
+Date:   Fri Apr 27 11:09:24 2018 +0200
+
+correct the large buffer problem with newer versions of pcscd
+
+--- a/cjeca32/EC30Reader.cpp
 b/cjeca32/EC30Reader.cpp
+@@ -162,21 +162,23 @@ CJ_RESULT CEC30Reader::CtApplicationData
+ {
+int Res;
+   uint32_t Len;
+-  uint16_t wLenRsp=0;
+-  uint16_t wLenErr=0;
++  uint32_t wLenRsp=0;
++  uint32_t wLenErr=0;
+   if(ResponseLen!=0)
+-  wLenRsp=(uint16_t)*ResponseLen;
++  wLenRsp=*ResponseLen;
+   if(ApplicationErrorLength!=NULL)
+-  wLenErr=(uint16_t)*ApplicationErrorLength;
+-  if(m_nApplicationResponseLength<(uint32_t)wLenRsp+wLenErr+4)
++  wLenErr=*ApplicationErrorLength;
++  Len=4+wLenRsp+wLenErr;
++  if(m_nApplicationResponseLength0xFFFB) // overflow or bigger than 0x - 4
++  return CJ_ERR_WRONG_PARAMETER;
+ 
+   
if((Res=Escape(ApplicationID,Function,InputData,InputLen,Result,m_pApplicationResponse,,Slot)))
+   {
+@@ -186,10 +188,14 @@ CJ_RESULT CEC30Reader::CtApplicationData
+   *ApplicationErrorLength=0;
+   return Res;
+   }
+-  memcpy(,m_pApplicationResponse,sizeof(wLenRsp));
+-  wLenRsp=ReaderToHostShort(wLenRsp);
+-  memcpy(,m_pApplicationResponse+2,sizeof(wLenErr));
+-  wLenErr=ReaderToHostShort(wLenErr);
++
++  uint16_t wLenRsp16 = 0;
++  uint16_t wLenErr16 = 0;
++  memcpy(,m_pApplicationResponse,sizeof(wLenRsp16));
++  wLenRsp=ReaderToHostShort(wLenRsp16);
++  memcpy(,m_pApplicationResponse+2,sizeof(wLenErr16));
++  wLenErr=ReaderToHostShort(wLenErr16);
++
+   if(ApplicationErrorLength)
+   {
+   if(wLenErr>*ApplicationErrorLength)

Bug#926103: Freeze-exception for pcsc-cyberjack 3.99.5final.sp09-2

[Reinhard Tartler]

Hi Release Team,

Frank and I would like to see RC bug #926103 fixed in Debian 10. Please approve 
the attached debdiff, so that I can upload the fixed package to unstable.

Thank you for your consideration.

Best,
Reinhard
diff -Nru pcsc-cyberjack-3.99.5final.sp09/debian/changelog 
pcsc-cyberjack-3.99.5final.sp09/debian/changelog
--- pcsc-cyberjack-3.99.5final.sp09/debian/changelog2017-05-29 
14:33:13.0 -0400
+++ pcsc-cyberjack-3.99.5final.sp09/debian/changelog2019-04-08 
17:58:31.0 -0400
@@ -1,3 +1,11 @@
+pcsc-cyberjack (3.99.5final.sp09-2) unstable; urgency=medium
+
+  * Acknoledge NMU.
+  * Bug fix: "driver breaks with pcsc-lite versions >= 1.8.21", thanks
+to Peter Wienemann (Closes: #926103).
+
+ -- Reinhard Tartler   Mon, 08 Apr 2019 17:58:31 -0400
+
 pcsc-cyberjack (3.99.5final.sp09-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru pcsc-cyberjack-3.99.5final.sp09/debian/patches/series 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/series
--- pcsc-cyberjack-3.99.5final.sp09/debian/patches/series   2017-05-29 
14:33:11.0 -0400
+++ pcsc-cyberjack-3.99.5final.sp09/debian/patches/series   2019-04-08 
17:58:31.0 -0400
@@ -1 +1,2 @@
 enable_pinpad_ecom.patch
+work-with-newer-pcsc-lite.patch
diff -Nru 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch
--- 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch  
1969-12-31 19:00:00.0 -0500
+++ 
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch  
2019-04-08 17:58:31.0 -0400
@@ -0,0 +1,58 @@
+commit 8ab61acfa0a8efc3c65098d4c621d761b7e05da1
+Author: Frank Neuber 
+Date:   Fri Apr 27 11:09:24 2018 +0200
+
+correct the large buffer problem with newer versions of pcscd
+
+--- a/cjeca32/EC30Reader.cpp
 b/cjeca32/EC30Reader.cpp
+@@ -162,21 +162,23 @@ CJ_RESULT CEC30Reader::CtApplicationData
+ {
+int Res;
+   uint32_t Len;
+-  uint16_t wLenRsp=0;
+-  uint16_t wLenErr=0;
++  uint32_t wLenRsp=0;
++  uint32_t wLenErr=0;
+   if(ResponseLen!=0)
+-  wLenRsp=(uint16_t)*ResponseLen;
++  wLenRsp=*ResponseLen;
+   if(ApplicationErrorLength!=NULL)
+-  wLenErr=(uint16_t)*ApplicationErrorLength;
+-  if(m_nApplicationResponseLength<(uint32_t)wLenRsp+wLenErr+4)
++  wLenErr=*ApplicationErrorLength;
++  Len=4+wLenRsp+wLenErr;
++  if(m_nApplicationResponseLength0xFFFB) // overflow or bigger than 0x - 4
++  return CJ_ERR_WRONG_PARAMETER;
+ 
+   
if((Res=Escape(ApplicationID,Function,InputData,InputLen,Result,m_pApplicationResponse,,Slot)))
+   {
+@@ -186,10 +188,14 @@ CJ_RESULT CEC30Reader::CtApplicationData
+   *ApplicationErrorLength=0;
+   return Res;
+   }
+-  memcpy(,m_pApplicationResponse,sizeof(wLenRsp));
+-  wLenRsp=ReaderToHostShort(wLenRsp);
+-  memcpy(,m_pApplicationResponse+2,sizeof(wLenErr));
+-  wLenErr=ReaderToHostShort(wLenErr);
++
++  uint16_t wLenRsp16 = 0;
++  uint16_t wLenErr16 = 0;
++  memcpy(,m_pApplicationResponse,sizeof(wLenRsp16));
++  wLenRsp=ReaderToHostShort(wLenRsp16);
++  memcpy(,m_pApplicationResponse+2,sizeof(wLenErr16));
++  wLenErr=ReaderToHostShort(wLenErr16);
++
+   if(ApplicationErrorLength)
+   {
+   if(wLenErr>*ApplicationErrorLength)

Accepted pcsc-cyberjack 3.99.5final.sp13+dfsg-1 (source) into experimental

[Reinhard Tartler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 08 Apr 2019 17:39:58 -0400
Source: pcsc-cyberjack
Architecture: source
Version: 3.99.5final.sp13+dfsg-1
Distribution: experimental
Urgency: medium
Maintainer: Frank Neuber 
Changed-By: Reinhard Tartler 
Closes: 850625 923588 926103
Changes:
 pcsc-cyberjack (3.99.5final.sp13+dfsg-1) experimental; urgency=medium
 .
   * New upstream release (Closes: #923588)
 - Bug fix: "driver breaks with pcsc-lite versions >= 1.8.21"
  (Closes: #926103)
   * No longer install cyberjack.8 manpage (Closes: #850625)
Checksums-Sha1:
 819bd613c7dfe93f3bcc964a895a761bde7a6005 2273 
pcsc-cyberjack_3.99.5final.sp13+dfsg-1.dsc
 4876e6b1d2e9af43d6d58bc6b6a4230a8250f37c 1032256 
pcsc-cyberjack_3.99.5final.sp13+dfsg.orig.tar.xz
 8391e5843d89ec9a809aeb883ac2f9e989194500 4408 
pcsc-cyberjack_3.99.5final.sp13+dfsg-1.debian.tar.xz
Checksums-Sha256:
 f87bf7a666deb02a4264e59e3aee8c28bc82f32687b078da0c9699fc77cfbf63 2273 
pcsc-cyberjack_3.99.5final.sp13+dfsg-1.dsc
 8a249d7785e0682d69fafa38186e897fca328f05ed8178e13e98f22d4a994085 1032256 
pcsc-cyberjack_3.99.5final.sp13+dfsg.orig.tar.xz
 3f56860e163642b79621a9b625470b56c8c502654535673315c6736ad1d592fd 4408 
pcsc-cyberjack_3.99.5final.sp13+dfsg-1.debian.tar.xz
Files:
 666a7ca44d16f0e4c9eb945c2dfb0db8 2273 misc optional 
pcsc-cyberjack_3.99.5final.sp13+dfsg-1.dsc
 f152a8475e3ab8814ba967078569f1e0 1032256 misc optional 
pcsc-cyberjack_3.99.5final.sp13+dfsg.orig.tar.xz
 4f21145f414278ee0b71291166c0dbe6 4408 misc optional 
pcsc-cyberjack_3.99.5final.sp13+dfsg-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQJIBAEBCgAyFiEEMN59F2OrlFLH4IJQSadpd5QoJssFAlyrwe0UHHNpcmV0YXJ0
QHRhdXdhcmUuZGUACgkQSadpd5QoJssaPRAAz0g2ltMYiHSk5SQX0EKOmwqOwyvk
cwBJ5oSfVPa7k9STW68Mzm4V82B6dDRRCez1r8ozJID85/5kx4TFpVlf4Dv1eZzy
M+V44yNB0rC0Mei+O/hCje9Lr/SS0icoWruhMkBTD/ygNE91ko3GoHM9mfmEyaWj
xcFTXopYJHJgaG7CzWDEZT8tNCmUVVEuO4U+qoCwZ6Y1iJG27oYhwlVPkep+Fxzd
RmkmURzFcbTW4DPruIgNsCbvYv2tUsBby3Tx/m3bh6rczS/ExKFvQ/hJQKSo/Mu5
EtFd5TyYJbZoOF/LCmTPPVq/VzKnKtpR9zxp/Gmt21W+fg+KruDa69ZmAA35DUsi
M27YmjqauaXs33zgw3bao9gFsfjdWXw6Jg/NOB32oMLAvqUmg0HAjs4VfvHaDCVv
x4xMzfWvesNyhHzZ0dk7eaoEH97wjrjqImwJOR0NhQT+t8obVGb1TEvrP2k+Qcjc
faZdkidUmNpNi7Qq+nad9HBb4IyLOnjt+ADY2pkdKXHWIHZ0jlehKgUwY7oWMKbU
vAQuZmRkX133n8JGfgzyohIHGdtVhkyMr+XVDxxBvuDaozSDn3/vF1o48Ko5YMwB
gb9h5kM5OD8Xga9jpkshMeSXTduYFsLE9C16HJeNGZ0C+7ux+9L2JOdx8tW31VkG
ZzWgsWD+MpKodQ8=
=XH7h
-END PGP SIGNATURE-

Accepted pcsc-cyberjack 3.99.5final.sp13+dfsg-1 (source) into experimental

[Reinhard Tartler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 08 Apr 2019 17:39:58 -0400
Source: pcsc-cyberjack
Architecture: source
Version: 3.99.5final.sp13+dfsg-1
Distribution: experimental
Urgency: medium
Maintainer: Frank Neuber 
Changed-By: Reinhard Tartler 
Closes: 850625 923588 926103
Changes:
 pcsc-cyberjack (3.99.5final.sp13+dfsg-1) experimental; urgency=medium
 .
   * New upstream release (Closes: #923588)
 - Bug fix: "driver breaks with pcsc-lite versions >= 1.8.21"
  (Closes: #926103)
   * No longer install cyberjack.8 manpage (Closes: #850625)
Checksums-Sha1:
 819bd613c7dfe93f3bcc964a895a761bde7a6005 2273 
pcsc-cyberjack_3.99.5final.sp13+dfsg-1.dsc
 4876e6b1d2e9af43d6d58bc6b6a4230a8250f37c 1032256 
pcsc-cyberjack_3.99.5final.sp13+dfsg.orig.tar.xz
 8391e5843d89ec9a809aeb883ac2f9e989194500 4408 
pcsc-cyberjack_3.99.5final.sp13+dfsg-1.debian.tar.xz
Checksums-Sha256:
 f87bf7a666deb02a4264e59e3aee8c28bc82f32687b078da0c9699fc77cfbf63 2273 
pcsc-cyberjack_3.99.5final.sp13+dfsg-1.dsc
 8a249d7785e0682d69fafa38186e897fca328f05ed8178e13e98f22d4a994085 1032256 
pcsc-cyberjack_3.99.5final.sp13+dfsg.orig.tar.xz
 3f56860e163642b79621a9b625470b56c8c502654535673315c6736ad1d592fd 4408 
pcsc-cyberjack_3.99.5final.sp13+dfsg-1.debian.tar.xz
Files:
 666a7ca44d16f0e4c9eb945c2dfb0db8 2273 misc optional 
pcsc-cyberjack_3.99.5final.sp13+dfsg-1.dsc
 f152a8475e3ab8814ba967078569f1e0 1032256 misc optional 
pcsc-cyberjack_3.99.5final.sp13+dfsg.orig.tar.xz
 4f21145f414278ee0b71291166c0dbe6 4408 misc optional 
pcsc-cyberjack_3.99.5final.sp13+dfsg-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQJIBAEBCgAyFiEEMN59F2OrlFLH4IJQSadpd5QoJssFAlyrwe0UHHNpcmV0YXJ0
QHRhdXdhcmUuZGUACgkQSadpd5QoJssaPRAAz0g2ltMYiHSk5SQX0EKOmwqOwyvk
cwBJ5oSfVPa7k9STW68Mzm4V82B6dDRRCez1r8ozJID85/5kx4TFpVlf4Dv1eZzy
M+V44yNB0rC0Mei+O/hCje9Lr/SS0icoWruhMkBTD/ygNE91ko3GoHM9mfmEyaWj
xcFTXopYJHJgaG7CzWDEZT8tNCmUVVEuO4U+qoCwZ6Y1iJG27oYhwlVPkep+Fxzd
RmkmURzFcbTW4DPruIgNsCbvYv2tUsBby3Tx/m3bh6rczS/ExKFvQ/hJQKSo/Mu5
EtFd5TyYJbZoOF/LCmTPPVq/VzKnKtpR9zxp/Gmt21W+fg+KruDa69ZmAA35DUsi
M27YmjqauaXs33zgw3bao9gFsfjdWXw6Jg/NOB32oMLAvqUmg0HAjs4VfvHaDCVv
x4xMzfWvesNyhHzZ0dk7eaoEH97wjrjqImwJOR0NhQT+t8obVGb1TEvrP2k+Qcjc
faZdkidUmNpNi7Qq+nad9HBb4IyLOnjt+ADY2pkdKXHWIHZ0jlehKgUwY7oWMKbU
vAQuZmRkX133n8JGfgzyohIHGdtVhkyMr+XVDxxBvuDaozSDn3/vF1o48Ko5YMwB
gb9h5kM5OD8Xga9jpkshMeSXTduYFsLE9C16HJeNGZ0C+7ux+9L2JOdx8tW31VkG
ZzWgsWD+MpKodQ8=
=XH7h
-END PGP SIGNATURE-

Re: gpac_0.7.1+dfsg1-1_amd64.changes is NEW

[Reinhard Tartler]

On 4/4/19 3:38 PM, Moritz Mühlenhoff wrote:
> On Tue, Apr 02, 2019 at 10:40:44PM -0400, Reinhard Tartler wrote:
>> Ah, that's great news. I didn't realize that Moritz backported the
>> security fixes to an earlier upstream version. I managed to locate the
>> git commits but wasn't comfortable with backporting them to version 0.5.2,
>> not all of them applied cleanly and I lacked the confidence to resolve
>> the conflicts.
>>
>> Thanks Moritz for taking care of this!
> 
> Yeah, I sent a mail to debian-multimedia@ldo about this, but seems to have
> fallen through the cracks:
> https://lists.debian.org/debian-multimedia/2019/03/msg00081.html

That's entirely possible, I must have overlooked that email. My apologies.


> BTW, I also prepared an MR on salsa for the remaining open security issues
> in src:audiofile, it would be great if anyone in the debian multimedia
> team could merge and upload:
> https://salsa.debian.org/multimedia-team/audiofile/merge_requests/1

Seems Sebastian already took care of this and the upload last Friday. :-)

 
>> Given we do have those RC bugs fixed with more targeted patches, I
>> no longer see the urgency to get 0.7.1 into unstable. Would you agree
>> with having 0.7.1 in experimental instead? If so, I'd upload it as
>> 0.7.1-2 to experimental.
> 
> experimental should be fine, as it's totally to the freeze process.

Uploaded 0.7.1-2 to experimental, which is (again) in NEW. Thorsten,
let me know if there are any issues with that upload.

Cheers,
-rt




signature.asc
Description: OpenPGP digital signature

Re: gpac_0.7.1+dfsg1-1_amd64.changes is NEW

[Reinhard Tartler]

On 4/4/19 3:38 PM, Moritz Mühlenhoff wrote:
> On Tue, Apr 02, 2019 at 10:40:44PM -0400, Reinhard Tartler wrote:
>> Ah, that's great news. I didn't realize that Moritz backported the
>> security fixes to an earlier upstream version. I managed to locate the
>> git commits but wasn't comfortable with backporting them to version 0.5.2,
>> not all of them applied cleanly and I lacked the confidence to resolve
>> the conflicts.
>>
>> Thanks Moritz for taking care of this!
> 
> Yeah, I sent a mail to debian-multimedia@ldo about this, but seems to have
> fallen through the cracks:
> https://lists.debian.org/debian-multimedia/2019/03/msg00081.html

That's entirely possible, I must have overlooked that email. My apologies.


> BTW, I also prepared an MR on salsa for the remaining open security issues
> in src:audiofile, it would be great if anyone in the debian multimedia
> team could merge and upload:
> https://salsa.debian.org/multimedia-team/audiofile/merge_requests/1

Seems Sebastian already took care of this and the upload last Friday. :-)

 
>> Given we do have those RC bugs fixed with more targeted patches, I
>> no longer see the urgency to get 0.7.1 into unstable. Would you agree
>> with having 0.7.1 in experimental instead? If so, I'd upload it as
>> 0.7.1-2 to experimental.
> 
> experimental should be fine, as it's totally to the freeze process.

Uploaded 0.7.1-2 to experimental, which is (again) in NEW. Thorsten,
let me know if there are any issues with that upload.

Cheers,
-rt




signature.asc
Description: OpenPGP digital signature

Re: gpac_0.7.1+dfsg1-1_amd64.changes is NEW

[Reinhard Tartler]

On 4/2/19 3:08 PM, Niels Thykier wrote:
> Thorsten Alteholz:
>> Hi Reinhard,
>>
>> On Tue, 2 Apr 2019, Reinhard Tartler wrote:
>>> Now about 6 weeks have passed since I've been uploading this package, and
>>> I do have a question: Is there anything wrong with this package?
>>
>> yes, you did an upload to unstable. At this time of the freeze and
>> without a notice from the maintainer/release team this is usually wrong.

I did the upload on 2/15. At the time of the upload, I missed the deadline
for the soft freeze by three days. I don't consider this a large or disruptive
change so I uploaded the package hoping it to get accepted anyways.

Admittedly, I then lost track of this package and realized only earlier today
that it still hadn't made it to unstable. My bad, sorry!

>>> I'm CC'ing the release team to inform them about this upload.
>>
>> Ok, so is this version suitable for buster?
>>
>>   Thorsten
>>
> 
> Note that gpac/0.5.2-426-gc5ad4e4+dfsg5-4.1 is currently in sid,
> recorded as fixing #892526, #902782 and #921969.  Therefore, please hold
> gpac/0.7.1+dfsg1-1 in NEW for now until the sid version can migrate to
> testing.

Ah, that's great news. I didn't realize that Moritz backported the
security fixes to an earlier upstream version. I managed to locate the
git commits but wasn't comfortable with backporting them to version 0.5.2,
not all of them applied cleanly and I lacked the confidence to resolve
the conflicts.

Thanks Moritz for taking care of this!

> 
> As for gpac/0.7.1+dfsg1-1, I cannot find a debdiff for it on the mailing
> list nor the BTS.  Therefore, I have no clue whether it is suitable for
> buster.

The debdiff is unreasonably large (several MiB), there are a *lot* of
unrelated upstream changes included.

I'll spare you to review it.

Given we do have those RC bugs fixed with more targeted patches, I
no longer see the urgency to get 0.7.1 into unstable. Would you agree
with having 0.7.1 in experimental instead? If so, I'd upload it as
0.7.1-2 to experimental.

Let me know if you have any thoughts or concerns on that.

Best,
-rt

Re: gpac_0.7.1+dfsg1-1_amd64.changes is NEW

[Reinhard Tartler]

On 4/2/19 3:08 PM, Niels Thykier wrote:
> Thorsten Alteholz:
>> Hi Reinhard,
>>
>> On Tue, 2 Apr 2019, Reinhard Tartler wrote:
>>> Now about 6 weeks have passed since I've been uploading this package, and
>>> I do have a question: Is there anything wrong with this package?
>>
>> yes, you did an upload to unstable. At this time of the freeze and
>> without a notice from the maintainer/release team this is usually wrong.

I did the upload on 2/15. At the time of the upload, I missed the deadline
for the soft freeze by three days. I don't consider this a large or disruptive
change so I uploaded the package hoping it to get accepted anyways.

Admittedly, I then lost track of this package and realized only earlier today
that it still hadn't made it to unstable. My bad, sorry!

>>> I'm CC'ing the release team to inform them about this upload.
>>
>> Ok, so is this version suitable for buster?
>>
>>   Thorsten
>>
> 
> Note that gpac/0.5.2-426-gc5ad4e4+dfsg5-4.1 is currently in sid,
> recorded as fixing #892526, #902782 and #921969.  Therefore, please hold
> gpac/0.7.1+dfsg1-1 in NEW for now until the sid version can migrate to
> testing.

Ah, that's great news. I didn't realize that Moritz backported the
security fixes to an earlier upstream version. I managed to locate the
git commits but wasn't comfortable with backporting them to version 0.5.2,
not all of them applied cleanly and I lacked the confidence to resolve
the conflicts.

Thanks Moritz for taking care of this!

> 
> As for gpac/0.7.1+dfsg1-1, I cannot find a debdiff for it on the mailing
> list nor the BTS.  Therefore, I have no clue whether it is suitable for
> buster.

The debdiff is unreasonably large (several MiB), there are a *lot* of
unrelated upstream changes included.

I'll spare you to review it.

Given we do have those RC bugs fixed with more targeted patches, I
no longer see the urgency to get 0.7.1 into unstable. Would you agree
with having 0.7.1 in experimental instead? If so, I'd upload it as
0.7.1-2 to experimental.

Let me know if you have any thoughts or concerns on that.

Best,
-rt

Re: gpac_0.7.1+dfsg1-1_amd64.changes is NEW

[Reinhard Tartler]

Dear ftp-master team,

On 2/15/19 7:20 AM, Debian FTP Masters wrote:
> binary:libgpac7 is NEW.
> binary:libgpac7 is NEW.
> 
> Your package has been put into the NEW queue, which requires manual action
> from the ftpteam to process. The upload was otherwise valid (it had a good
> OpenPGP signature and file hashes are valid), so please be patient.
> 
> Packages are routinely processed through to the archive, and do feel
> free to browse the NEW queue[1].
> 
> If there is an issue with the upload, you will receive an email from a
> member of the ftpteam.
> 
> If you have any questions, you may reply to this email.

Now about 6 weeks have passed since I've been uploading this package, and
I do have a question: Is there anything wrong with this package? As you can
see from https://ftp-master.debian.org/new/gpac_0.7.1+dfsg1-1.html, it fixes
RC bugs, and I would recommend to include it in the next stable release,
buster.

Please let me know if you have any questions and concerns about this upload.

I'm CC'ing the release team to inform them about this upload. It will
require a binNMU of the only dependent package, x264. I've test-built it
locally and don't expect any issues with that.

Thank you for your consideration.

Best,
Reinhard

Re: gpac_0.7.1+dfsg1-1_amd64.changes is NEW

[Reinhard Tartler]

Dear ftp-master team,

On 2/15/19 7:20 AM, Debian FTP Masters wrote:
> binary:libgpac7 is NEW.
> binary:libgpac7 is NEW.
> 
> Your package has been put into the NEW queue, which requires manual action
> from the ftpteam to process. The upload was otherwise valid (it had a good
> OpenPGP signature and file hashes are valid), so please be patient.
> 
> Packages are routinely processed through to the archive, and do feel
> free to browse the NEW queue[1].
> 
> If there is an issue with the upload, you will receive an email from a
> member of the ftpteam.
> 
> If you have any questions, you may reply to this email.

Now about 6 weeks have passed since I've been uploading this package, and
I do have a question: Is there anything wrong with this package? As you can
see from https://ftp-master.debian.org/new/gpac_0.7.1+dfsg1-1.html, it fixes
RC bugs, and I would recommend to include it in the next stable release,
buster.

Please let me know if you have any questions and concerns about this upload.

I'm CC'ing the release team to inform them about this upload. It will
require a binNMU of the only dependent package, x264. I've test-built it
locally and don't expect any issues with that.

Thank you for your consideration.

Best,
Reinhard

Accepted slirp4netns 0.3.0-1 (source) into experimental

[Reinhard Tartler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 30 Mar 2019 11:02:30 -0400
Source: slirp4netns
Binary: slirp4netns
Architecture: source
Version: 0.3.0-1
Distribution: experimental
Urgency: medium
Maintainer: Reinhard Tartler 
Changed-By: Reinhard Tartler 
Description:
 slirp4netns - User-mode networking for unprivileged network namespaces
Changes:
 slirp4netns (0.3.0-1) experimental; urgency=medium
 .
   * new upstream release
Checksums-Sha1:
 36220110a84529b723081e4af616b4b90c51b91f 2103 slirp4netns_0.3.0-1.dsc
 3b4319d406cf4a041b351bd847a22cc4d2c541c6 180149 slirp4netns_0.3.0.orig.tar.gz
 14acd65bd0a3282ad7786fe1c9d8e7402a93b354 4060 slirp4netns_0.3.0-1.debian.tar.xz
Checksums-Sha256:
 469ef25923eb449ce9d240a718fb30cd69c4883cf41b0d0f5cd2f513a6c94695 2103 
slirp4netns_0.3.0-1.dsc
 a222c6da9d2658f5c957d5ce494fa7e2f9f52150cd7aae40d1a782653daabf27 180149 
slirp4netns_0.3.0.orig.tar.gz
 e8f3067df92b9188b8dedabe7a4149c4972aa139313951fbf983f2fe7b83fd92 4060 
slirp4netns_0.3.0-1.debian.tar.xz
Files:
 bafd643af9ca858a67cdab2a1d06c7ba 2103 misc optional slirp4netns_0.3.0-1.dsc
 984c75289f251e44d15689f3612a6520 180149 misc optional 
slirp4netns_0.3.0.orig.tar.gz
 9e44b18c54ad44758a65947a1ee13a6c 4060 misc optional 
slirp4netns_0.3.0-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQJIBAEBCAAyFiEE6n5rckvJ+/LRcetya3IL6cXPbZ4FAlyg1WsUHHNpcmV0YXJ0
QHRhdXdhcmUuZGUACgkQa3IL6cXPbZ5h2g/+OxRaUfSTXSDlsd6eBGRr3g4a6nmZ
D3FEx4+O4vhY79dmqCsM7KBXebzcp65o3XxU3+knk422n38VCssHvGY2qdeH7aXP
fZwy3pfGmCCtLA2+qo4k9mDQ2Bl9AQGkFBBYnYJgHos/ZwXyVXLzJp+cuCvD9PEe
RkAbdMOXVh0dAByhhbuMCAuYdoZ9QrOfKVzuuT+kPVn/49L0Czn75MmDtli/Vsfe
eVqmk/5AIMS/+508BuhW52vRr4He33VbEjiuP55jRcDEzIl7V7JsTr+8rSItAEfd
6aVRhEJ+63879DoxprPUlRrZtRZwurz/atPcsK4Cl1vPzW5fQVuOFpS6+KskjfjZ
6O3gLwrDl5pamwKyg/zs4Jp6IPPeqT871yMAK9JXYlbrzArqno9tftIByxFCoHSj
1Y0/9MViA4o5N601CjJzLyr3de2DUMTTY2pkNupfns+xcAYtTttxUz9BIMwBpewK
mJSqk3GtJb0+YU1Xzbc0QcfyZTC0YoIo67lXbfmKffmjupjNMfs0H1tvPtOgHgzo
5YsbUfcBzfH2ezFa2m4omz4k1nYTkDJMO+uqNtkDcADZt766xm7e9ENt9ZUBu8XT
ylfxj28UczI+BfbtFT1HdJnnqhQ6GRmQ3F3utjr6qZT0iaYEBiILGhAimtWDLd0P
awS/rQ+5nPDG5JI=
=ED/I
-END PGP SIGNATURE-

Accepted slirp4netns 0.3.0-1 (source) into experimental

[Reinhard Tartler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 30 Mar 2019 11:02:30 -0400
Source: slirp4netns
Binary: slirp4netns
Architecture: source
Version: 0.3.0-1
Distribution: experimental
Urgency: medium
Maintainer: Reinhard Tartler 
Changed-By: Reinhard Tartler 
Description:
 slirp4netns - User-mode networking for unprivileged network namespaces
Changes:
 slirp4netns (0.3.0-1) experimental; urgency=medium
 .
   * new upstream release
Checksums-Sha1:
 36220110a84529b723081e4af616b4b90c51b91f 2103 slirp4netns_0.3.0-1.dsc
 3b4319d406cf4a041b351bd847a22cc4d2c541c6 180149 slirp4netns_0.3.0.orig.tar.gz
 14acd65bd0a3282ad7786fe1c9d8e7402a93b354 4060 slirp4netns_0.3.0-1.debian.tar.xz
Checksums-Sha256:
 469ef25923eb449ce9d240a718fb30cd69c4883cf41b0d0f5cd2f513a6c94695 2103 
slirp4netns_0.3.0-1.dsc
 a222c6da9d2658f5c957d5ce494fa7e2f9f52150cd7aae40d1a782653daabf27 180149 
slirp4netns_0.3.0.orig.tar.gz
 e8f3067df92b9188b8dedabe7a4149c4972aa139313951fbf983f2fe7b83fd92 4060 
slirp4netns_0.3.0-1.debian.tar.xz
Files:
 bafd643af9ca858a67cdab2a1d06c7ba 2103 misc optional slirp4netns_0.3.0-1.dsc
 984c75289f251e44d15689f3612a6520 180149 misc optional 
slirp4netns_0.3.0.orig.tar.gz
 9e44b18c54ad44758a65947a1ee13a6c 4060 misc optional 
slirp4netns_0.3.0-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQJIBAEBCAAyFiEE6n5rckvJ+/LRcetya3IL6cXPbZ4FAlyg1WsUHHNpcmV0YXJ0
QHRhdXdhcmUuZGUACgkQa3IL6cXPbZ5h2g/+OxRaUfSTXSDlsd6eBGRr3g4a6nmZ
D3FEx4+O4vhY79dmqCsM7KBXebzcp65o3XxU3+knk422n38VCssHvGY2qdeH7aXP
fZwy3pfGmCCtLA2+qo4k9mDQ2Bl9AQGkFBBYnYJgHos/ZwXyVXLzJp+cuCvD9PEe
RkAbdMOXVh0dAByhhbuMCAuYdoZ9QrOfKVzuuT+kPVn/49L0Czn75MmDtli/Vsfe
eVqmk/5AIMS/+508BuhW52vRr4He33VbEjiuP55jRcDEzIl7V7JsTr+8rSItAEfd
6aVRhEJ+63879DoxprPUlRrZtRZwurz/atPcsK4Cl1vPzW5fQVuOFpS6+KskjfjZ
6O3gLwrDl5pamwKyg/zs4Jp6IPPeqT871yMAK9JXYlbrzArqno9tftIByxFCoHSj
1Y0/9MViA4o5N601CjJzLyr3de2DUMTTY2pkNupfns+xcAYtTttxUz9BIMwBpewK
mJSqk3GtJb0+YU1Xzbc0QcfyZTC0YoIo67lXbfmKffmjupjNMfs0H1tvPtOgHgzo
5YsbUfcBzfH2ezFa2m4omz4k1nYTkDJMO+uqNtkDcADZt766xm7e9ENt9ZUBu8XT
ylfxj28UczI+BfbtFT1HdJnnqhQ6GRmQ3F3utjr6qZT0iaYEBiILGhAimtWDLd0P
awS/rQ+5nPDG5JI=
=ED/I
-END PGP SIGNATURE-

Accepted golang-github-appc-cni 0.7.0~rc2-1 (source) into experimental

[Reinhard Tartler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 03 Mar 2019 14:16:15 -0500
Source: golang-github-appc-cni
Binary: golang-github-appc-cni-dev
Architecture: source
Version: 0.7.0~rc2-1
Distribution: experimental
Urgency: medium
Maintainer: Debian Go Packaging Team 

Changed-By: Reinhard Tartler 
Description:
 golang-github-appc-cni-dev - container network interface
Changes:
 golang-github-appc-cni (0.7.0~rc2-1) experimental; urgency=medium
 .
   * Team Upload
   * New upstream release
Checksums-Sha1:
 21d3d36431ca6af9dfd9fc98920a255067b72e59 2499 
golang-github-appc-cni_0.7.0~rc2-1.dsc
 16d3e4d3410c0ce330acf423b05efb76a4271199 77880 
golang-github-appc-cni_0.7.0~rc2.orig.tar.xz
 87b034f3638daea2b7ccf3e051815107b5682420 2732 
golang-github-appc-cni_0.7.0~rc2-1.debian.tar.xz
 d237c32701b4916cba04253e192a71f0081b070c 6035 
golang-github-appc-cni_0.7.0~rc2-1_source.buildinfo
Checksums-Sha256:
 9cdf58debb901564b2b87fc6525fe866a46b2e22d59608ca3a40104f5fd78915 2499 
golang-github-appc-cni_0.7.0~rc2-1.dsc
 3b06d487825126c39f3f977ffab72ee9948c18dedba41bffcbf39fe3269ee02d 77880 
golang-github-appc-cni_0.7.0~rc2.orig.tar.xz
 aaa0d9563bdede18515b5dd680081efcdeaf5bc873a7919d6f7e8cd0ca9a14dd 2732 
golang-github-appc-cni_0.7.0~rc2-1.debian.tar.xz
 ca9f649f612ae66db615e90a7dd35396f6eaffe60f6fab0b48f83286782ae194 6035 
golang-github-appc-cni_0.7.0~rc2-1_source.buildinfo
Files:
 eadef7e069c9b1aedfe4101e53acfe6c 2499 devel optional 
golang-github-appc-cni_0.7.0~rc2-1.dsc
 3e87197bbefd57b2bb49f4e0fca5785b 77880 devel optional 
golang-github-appc-cni_0.7.0~rc2.orig.tar.xz
 a425f2d3645b27023c2ba877fc0d7a0d 2732 devel optional 
golang-github-appc-cni_0.7.0~rc2-1.debian.tar.xz
 429a89a4a1f0e9753ddbb7ca15abee0b 6035 devel optional 
golang-github-appc-cni_0.7.0~rc2-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJIBAEBCgAyFiEEMN59F2OrlFLH4IJQSadpd5QoJssFAlyVTw0UHHNpcmV0YXJ0
QGRlYmlhbi5vcmcACgkQSadpd5QoJsvtmRAAyhE3Ytp/xU4qWHZMRODv05b/7aMh
sSxYpc2t6x/VqI9ZDfcqzlAgyw0W1kd+AEV4DBpop9SCRLwvaaE5tDBLR52rs7gk
1ioBaxEbktsYdK9/lXStT29TK10mFL36xjIaALSUoSY+2dlu6Efbt7gW4EwNpTOw
GDByTHC+tq/laD5PmqlIdRLILG1JQ9UulKMJagjZMBOSCpSM7Ec73sZaPo7RONa/
pLKL56HOmY544O03MDVPW6E+MbMEu/U9baFU85Mv2RfL/e1nN2/LtdWiTzpqWWrG
sNa3dcUEx1tTHtHJAVg8H8LMEwk4kJUatfz4/vmIcj1NvytPjA+Ad5wdEaVrK9PT
9hzDeuSYzPbWv0MQ0SLk+U8Gk4lFL/QIHaTKQ0GpL1uHwVWJ9F4JRLkIxRaYZqB0
OdjlbFTSwXi5uLhXjIXLwbm6gn8pLhDtDgK8rrZBEa+ziKZykLF2E4DFdJV4SqFJ
AmUuCvVDcOSnBmkr0Datjks6Gra7aMKWxhVjQhuFH8JiCX3IdfOOUS0vS4dJVm8k
eYwUt538C3z92MxaiU6xMQKzl3KM4qnycXuqwXqqJQlx4RJPB4/bgUOwdqkzPci1
UxhI5b3i39xSHkU8HSh/6Y/vk02/VzzcdfWkiyClOG5rNNY8cLrSDtq+Fnx2CPbk
wDpds/Fi85t0PYU=
=WGov
-END PGP SIGNATURE-

Accepted golang-github-appc-cni 0.7.0~rc2-1 (source) into experimental

[Reinhard Tartler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 03 Mar 2019 14:16:15 -0500
Source: golang-github-appc-cni
Binary: golang-github-appc-cni-dev
Architecture: source
Version: 0.7.0~rc2-1
Distribution: experimental
Urgency: medium
Maintainer: Debian Go Packaging Team 

Changed-By: Reinhard Tartler 
Description:
 golang-github-appc-cni-dev - container network interface
Changes:
 golang-github-appc-cni (0.7.0~rc2-1) experimental; urgency=medium
 .
   * Team Upload
   * New upstream release
Checksums-Sha1:
 21d3d36431ca6af9dfd9fc98920a255067b72e59 2499 
golang-github-appc-cni_0.7.0~rc2-1.dsc
 16d3e4d3410c0ce330acf423b05efb76a4271199 77880 
golang-github-appc-cni_0.7.0~rc2.orig.tar.xz
 87b034f3638daea2b7ccf3e051815107b5682420 2732 
golang-github-appc-cni_0.7.0~rc2-1.debian.tar.xz
 d237c32701b4916cba04253e192a71f0081b070c 6035 
golang-github-appc-cni_0.7.0~rc2-1_source.buildinfo
Checksums-Sha256:
 9cdf58debb901564b2b87fc6525fe866a46b2e22d59608ca3a40104f5fd78915 2499 
golang-github-appc-cni_0.7.0~rc2-1.dsc
 3b06d487825126c39f3f977ffab72ee9948c18dedba41bffcbf39fe3269ee02d 77880 
golang-github-appc-cni_0.7.0~rc2.orig.tar.xz
 aaa0d9563bdede18515b5dd680081efcdeaf5bc873a7919d6f7e8cd0ca9a14dd 2732 
golang-github-appc-cni_0.7.0~rc2-1.debian.tar.xz
 ca9f649f612ae66db615e90a7dd35396f6eaffe60f6fab0b48f83286782ae194 6035 
golang-github-appc-cni_0.7.0~rc2-1_source.buildinfo
Files:
 eadef7e069c9b1aedfe4101e53acfe6c 2499 devel optional 
golang-github-appc-cni_0.7.0~rc2-1.dsc
 3e87197bbefd57b2bb49f4e0fca5785b 77880 devel optional 
golang-github-appc-cni_0.7.0~rc2.orig.tar.xz
 a425f2d3645b27023c2ba877fc0d7a0d 2732 devel optional 
golang-github-appc-cni_0.7.0~rc2-1.debian.tar.xz
 429a89a4a1f0e9753ddbb7ca15abee0b 6035 devel optional 
golang-github-appc-cni_0.7.0~rc2-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJIBAEBCgAyFiEEMN59F2OrlFLH4IJQSadpd5QoJssFAlyVTw0UHHNpcmV0YXJ0
QGRlYmlhbi5vcmcACgkQSadpd5QoJsvtmRAAyhE3Ytp/xU4qWHZMRODv05b/7aMh
sSxYpc2t6x/VqI9ZDfcqzlAgyw0W1kd+AEV4DBpop9SCRLwvaaE5tDBLR52rs7gk
1ioBaxEbktsYdK9/lXStT29TK10mFL36xjIaALSUoSY+2dlu6Efbt7gW4EwNpTOw
GDByTHC+tq/laD5PmqlIdRLILG1JQ9UulKMJagjZMBOSCpSM7Ec73sZaPo7RONa/
pLKL56HOmY544O03MDVPW6E+MbMEu/U9baFU85Mv2RfL/e1nN2/LtdWiTzpqWWrG
sNa3dcUEx1tTHtHJAVg8H8LMEwk4kJUatfz4/vmIcj1NvytPjA+Ad5wdEaVrK9PT
9hzDeuSYzPbWv0MQ0SLk+U8Gk4lFL/QIHaTKQ0GpL1uHwVWJ9F4JRLkIxRaYZqB0
OdjlbFTSwXi5uLhXjIXLwbm6gn8pLhDtDgK8rrZBEa+ziKZykLF2E4DFdJV4SqFJ
AmUuCvVDcOSnBmkr0Datjks6Gra7aMKWxhVjQhuFH8JiCX3IdfOOUS0vS4dJVm8k
eYwUt538C3z92MxaiU6xMQKzl3KM4qnycXuqwXqqJQlx4RJPB4/bgUOwdqkzPci1
UxhI5b3i39xSHkU8HSh/6Y/vk02/VzzcdfWkiyClOG5rNNY8cLrSDtq+Fnx2CPbk
wDpds/Fi85t0PYU=
=WGov
-END PGP SIGNATURE-

Bug#925184: ITP: golang-github-vbauerster-mpb -- multi progress bar for Go cli applications

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-vbauerster-mpb
  Version : 3.3.4-1
  Upstream Author : Vladimir Bauer
* URL : https://github.com/vbauerster/mpb
* License : BSD-3-clause
  Programming Lang: Go
  Description : multi progress bar for Go cli applications

 mpb is a golang library for rendering progress bars in terminal
 applications.

This package is a build-dependency for github.com/containers/buildah


This package is going to be team maintained by the golang team.

Bug#923300: Bug#924257: docker.io: Misses to install some golang packages

[Reinhard Tartler]

On 3/13/19 10:29 AM, Arnaud Rebillout wrote:
> On 3/13/19 6:47 PM, Reinhard Tartler wrote:
>> [...] could you please update debian/changelog in experimental, and provide 
>> me with a link to your pre-built *source* package [new version of 
>> src:docker.io]? I'd be happy to testbuild it here, ensure that 
>> github:openstack/imagebuilder still works, and sponsor the upload to 
>> experimental.
> 
> 
> I just pushed your patch to experimental, thanks again, and sorry for
> the back and forth. I don't have permissions to give you access to this
> repo, let me CC Dmitry so that he can give you permissions.

Great!

> 
> I didn't forget any commit, it's just that the package doesn't build
> with gbp, the pristine-tar and upstream branches are not used anymore.
> There's a procedure to know, nothing complicated, but nothing obvious
> either. Here comes the magic:
> 
>   # Clean the place if need be
>   git clean -dfx && git reset --hard
> 
>   # Import and unpack upstream sources (will trigger uscan and download
> orig tarballs if need be)
>   origtargz --unpack && ./debian/unpack-components.sh
> 
>   # Build with your favorite tool
>   dpkg-buildpackage -S -us -uc -i --no-check-builddeps 
> 
> 
> That's it, that should give you a source package.
>

Thanks for the clarification. I'm really not comfortable with git repositories 
for source packages, which choose to not include the full sources. I feel that 
they cause more trouble than that their work (for instance, I have to resort to 
http://sources.debian.org to inspect upstream sources), but I realize that 
others (for instance Dmitry) disagree here. Please excuse my questions for 
clarifications caused by ignorance here.

As for uploading the new version of src:docker.io to experimental, I 
successfully built the package from the sources at 
https://salsa.debian.org/docker-team/docker/tree/experimental, and confirmed 
that my locally updated version of the github.com/containers/storage packages 
continues to work (that package is currently still in the NEW queue). However, 
github.com/openshift/imagebuilder continues to fail to build. At first, I've 
identified a number of additional missing imports that I could resolve with the 
attached patch. Would that be acceptable to include in the next upload?

But even with this attached patch, I'm still running into compilation and have 
asked for help at 
https://github.com/openshift/imagebuilder/pull/125#issuecomment-473562682 - 
Upstream is really responsive and started to work on it at 
https://github.com/openshift/imagebuilder/pull/127 - at the time of writing, we 
are still working on clarifying and resolving the issue.


Best,
-rt
From 547c4f99d53b4a9382298d46b3a8066839e1f3ac Mon Sep 17 00:00:00 2001
From: Reinhard Tartler 
Date: Thu, 14 Mar 2019 07:52:46 -0400
Subject: [PATCH] Additional missing sources for openshift/imagebuilder

---
 debian/control | 5 +
 debian/golang-github-docker-docker-dev.install | 9 +
 2 files changed, 14 insertions(+)

diff --git a/debian/control b/debian/control
index 8e13a2ea..53cb9ccb 100644
--- a/debian/control
+++ b/debian/control
@@ -230,6 +230,11 @@ Depends: ${misc:Depends}
 ,golang-github-hashicorp-serf-dev
 ,golang-github-vishvananda-netlink-dev (>= 1.0.0~)
 ,golang-github-vishvananda-netns-dev
+# containerd
+,golang-github-tonistiigi-fifo-dev
+,golang-github-containerd-fifo-dev
+# moby/buildkit/session
+,golang-github-opentracing-opentracing-go-dev
 Replaces: golang-docker-dev (<< 1.8.2~ds1-1~)
 ,golang-github-docker-go-metrics-dev
 ,golang-github-docker-libnetwork-dev
diff --git a/debian/golang-github-docker-docker-dev.install b/debian/golang-github-docker-docker-dev.install
index 17d0abfb..89d21387 100644
--- a/debian/golang-github-docker-docker-dev.install
+++ b/debian/golang-github-docker-docker-dev.install
@@ -10,6 +10,7 @@
 
 ## Engine
 engine/dockerversionusr/share/gocode/src/github.com/docker/docker/
+engine/daemon   usr/share/gocode/src/github.com/docker/docker/
 .gopath/src/github.com/docker/docker/apiusr/share/gocode/src/github.com/docker/docker/
 .gopath/src/github.com/docker/docker/builderusr/share/gocode/src/github.com/docker/docker/
 .gopath/src/github.com/docker/docker/cliusr/share/gocode/src/github.com/docker/docker/
@@ -39,8 +40,12 @@ engine/dockerversionusr/share/gocode/src/github.
 
 
 ## Sub-vendoring:
+engine/vendor/github.com/containerd/continuity/devices   usr/share/gocode/src/github.com/docker/docker/vendor/github.com/containerd/continuity/
 engine/vendor/github.com/containerd/continuity/driverusr/share/gocode/src/github.com/docker/docker/vendor/github.com/containerd/continuity/
+engine/vendor/gi

Bug#923300: Bug#924257: docker.io: Misses to install some golang packages

[Reinhard Tartler]

On 3/13/19 10:29 AM, Arnaud Rebillout wrote:
> On 3/13/19 6:47 PM, Reinhard Tartler wrote:
>> [...] could you please update debian/changelog in experimental, and provide 
>> me with a link to your pre-built *source* package [new version of 
>> src:docker.io]? I'd be happy to testbuild it here, ensure that 
>> github:openstack/imagebuilder still works, and sponsor the upload to 
>> experimental.
> 
> 
> I just pushed your patch to experimental, thanks again, and sorry for
> the back and forth. I don't have permissions to give you access to this
> repo, let me CC Dmitry so that he can give you permissions.

Great!

> 
> I didn't forget any commit, it's just that the package doesn't build
> with gbp, the pristine-tar and upstream branches are not used anymore.
> There's a procedure to know, nothing complicated, but nothing obvious
> either. Here comes the magic:
> 
>   # Clean the place if need be
>   git clean -dfx && git reset --hard
> 
>   # Import and unpack upstream sources (will trigger uscan and download
> orig tarballs if need be)
>   origtargz --unpack && ./debian/unpack-components.sh
> 
>   # Build with your favorite tool
>   dpkg-buildpackage -S -us -uc -i --no-check-builddeps 
> 
> 
> That's it, that should give you a source package.
>

Thanks for the clarification. I'm really not comfortable with git repositories 
for source packages, which choose to not include the full sources. I feel that 
they cause more trouble than that their work (for instance, I have to resort to 
http://sources.debian.org to inspect upstream sources), but I realize that 
others (for instance Dmitry) disagree here. Please excuse my questions for 
clarifications caused by ignorance here.

As for uploading the new version of src:docker.io to experimental, I 
successfully built the package from the sources at 
https://salsa.debian.org/docker-team/docker/tree/experimental, and confirmed 
that my locally updated version of the github.com/containers/storage packages 
continues to work (that package is currently still in the NEW queue). However, 
github.com/openshift/imagebuilder continues to fail to build. At first, I've 
identified a number of additional missing imports that I could resolve with the 
attached patch. Would that be acceptable to include in the next upload?

But even with this attached patch, I'm still running into compilation and have 
asked for help at 
https://github.com/openshift/imagebuilder/pull/125#issuecomment-473562682 - 
Upstream is really responsive and started to work on it at 
https://github.com/openshift/imagebuilder/pull/127 - at the time of writing, we 
are still working on clarifying and resolving the issue.


Best,
-rt
From 547c4f99d53b4a9382298d46b3a8066839e1f3ac Mon Sep 17 00:00:00 2001
From: Reinhard Tartler 
Date: Thu, 14 Mar 2019 07:52:46 -0400
Subject: [PATCH] Additional missing sources for openshift/imagebuilder

---
 debian/control | 5 +
 debian/golang-github-docker-docker-dev.install | 9 +
 2 files changed, 14 insertions(+)

diff --git a/debian/control b/debian/control
index 8e13a2ea..53cb9ccb 100644
--- a/debian/control
+++ b/debian/control
@@ -230,6 +230,11 @@ Depends: ${misc:Depends}
 ,golang-github-hashicorp-serf-dev
 ,golang-github-vishvananda-netlink-dev (>= 1.0.0~)
 ,golang-github-vishvananda-netns-dev
+# containerd
+,golang-github-tonistiigi-fifo-dev
+,golang-github-containerd-fifo-dev
+# moby/buildkit/session
+,golang-github-opentracing-opentracing-go-dev
 Replaces: golang-docker-dev (<< 1.8.2~ds1-1~)
 ,golang-github-docker-go-metrics-dev
 ,golang-github-docker-libnetwork-dev
diff --git a/debian/golang-github-docker-docker-dev.install b/debian/golang-github-docker-docker-dev.install
index 17d0abfb..89d21387 100644
--- a/debian/golang-github-docker-docker-dev.install
+++ b/debian/golang-github-docker-docker-dev.install
@@ -10,6 +10,7 @@
 
 ## Engine
 engine/dockerversionusr/share/gocode/src/github.com/docker/docker/
+engine/daemon   usr/share/gocode/src/github.com/docker/docker/
 .gopath/src/github.com/docker/docker/apiusr/share/gocode/src/github.com/docker/docker/
 .gopath/src/github.com/docker/docker/builderusr/share/gocode/src/github.com/docker/docker/
 .gopath/src/github.com/docker/docker/cliusr/share/gocode/src/github.com/docker/docker/
@@ -39,8 +40,12 @@ engine/dockerversionusr/share/gocode/src/github.
 
 
 ## Sub-vendoring:
+engine/vendor/github.com/containerd/continuity/devices   usr/share/gocode/src/github.com/docker/docker/vendor/github.com/containerd/continuity/
 engine/vendor/github.com/containerd/continuity/driverusr/share/gocode/src/github.com/docker/docker/vendor/github.com/containerd/continuity/
+engine/vendor/gi

Bug#924270: O: keepassx -- Cross Platform Password Manager

[Reinhard Tartler]

On 3/11/19 1:09 PM, Felix Geyer wrote:

> I've replied to you but unfortunately your mail provider / filter seems to
> discard my mails.

I'm sorry to hear that. If gmail is giving you a hard time, feel free to contact
me on my @debian.org email address (or vice versa) in the future.

This email made it through just fine.

> I will continue maintaining KeePassX for the time being but likely only do
> important bugfixes and other necessary changes (like the port to Qt5).

I'm glad to hear that!


-rt

Bug#924270: O: keepassx -- Cross Platform Password Manager

[Reinhard Tartler]

On 3/11/19 1:09 PM, Felix Geyer wrote:

> I've replied to you but unfortunately your mail provider / filter seems to
> discard my mails.

I'm sorry to hear that. If gmail is giving you a hard time, feel free to contact
me on my @debian.org email address (or vice versa) in the future.

This email made it through just fine.

> I will continue maintaining KeePassX for the time being but likely only do
> important bugfixes and other necessary changes (like the port to Qt5).

I'm glad to hear that!


-rt

Bug#924257: docker.io: Misses to install some golang packages

[Reinhard Tartler]

On 3/13/19 3:54 AM, Arnaud Rebillout wrote:
> On 3/13/19 6:05 AM, Reinhard Tartler wrote:
>> I've implemented the change and confirmed that the attached patch does allow 
>> github.com/openstack/imagebuilder to be built successfully. As suggested, 
>> I've tried to push to salsa, but it seems I'm not permissioned to do so 
>> (docker.io is not under the go-team umbrella):
>>
>>   $ git push 
>>   GitLab: You are not allowed to push code to this project.
>>   fatal: Could not read from remote repository.
>>
>> Would you be able to upload the patch to experimental anytime soon? If it 
>> helped, I'd be happy to upload this patch as an NMU to experimental myself. 
>> Please let me know what works for you best.
> 
> I just pushed on the experimental branch, with some additional details
> afterwards. I also updated the docker package to latest version 18.09.3.
> 
> I'd be happy if you could upload to experimental, I don't think I have
> the permissions for that.

I'd be more than happy to upload this update on your behalf, but I'm running 
into technical issues.


1. It seems that the experimental branch fails to update debian/changelog. I've 
done so myself, please cf. to the attached patch
2. I am unable to build the source package:

>> gbp buildpackage -S
cat: VERSION: No such file or directory
cat: VERSION: No such file or directory
debian/rules:27: *** Missing DOCKER_GITCOMMIT - see 
debian/upstream-version-gitcommits.  Stop.
gbp:error: 'fakeroot debian/rules clean' failed: it exited with 2


I also tried to skip the cleaning step, but then I'm running into the issue of 
not finding the original tarballs:

>> gbp buildpackage --git-ignore-branch -d -nc --git-clean=true
gbp:info: Tarballs 'docker.io_18.09.3+dfsg1.orig.tar.gz' not found at 
'../tarballs/'
gbp:warning: Pristine-tar branch "pristine-tar" not found
gbp:error: Pristine-tar couldn't checkout 
"docker.io_18.09.3+dfsg1.orig.tar.gz": fatal: Path 
'docker.io_18.09.3+dfsg1.orig.tar.gz.delta' does not exist in 
'refs/remotes/salsa/pristine-tar'
pristine-tar: git show 
refs/remotes/salsa/pristine-tar:docker.io_18.09.3+dfsg1.orig.tar.gz.delta failed
zsh: exit 1 gbp buildpackage --git-ignore-branch -d -nc --git-clean=true

Possibly there are some unpushed commits on your computer? In either case, 
could you please update debian/changelog in experimental, and provide me with a 
link to your pre-built *source* package? I'd be happy to testbuild it here, 
ensure that github:openstack/imagebuilder still works, and sponsor the upload 
to experimental.

Cheers,
-rt
From 342fae58dfcc46f5a0d1ef2ac1ff9fc46ce04d8b Mon Sep 17 00:00:00 2001
From: Reinhard Tartler 
Date: Wed, 13 Mar 2019 07:40:48 -0400
Subject: [PATCH] debian/changelog: update

---
 debian/changelog | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 0994f1fa..f28a2adc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,14 @@
-docker.io (18.09.3+dfsg1-1) UNRELEASED; urgency=medium
+docker.io (18.09.3+dfsg1-1) experimental; urgency=medium
 
+  [ Arnaud Rebillout ]
   * New upstream release [March 2019].
+  * github-golang-docker-docker-dev: fix go-metrics install path.
+  * github-golang-docker-docker-dev: add replaces/breaks on docker-go-metrics-dev.
+
+  [ Reinhard Tartler ]
+  * github-golang-docker-docker-dev: add missing sources (Closes: #924257)
 
- -- Arnaud Rebillout   Wed, 06 Mar 2019 07:57:20 +0700
+ -- Arnaud Rebillout   Wed, 13 Mar 2019 07:40:05 -0400
 
 docker.io (18.09.1+dfsg1-5) unstable; urgency=medium
 
-- 
2.11.0

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Reinhard Tartler]

On Tue, Mar 12, 2019 at 1:49 PM Josh Triplett  wrote:

> On Tue, Mar 12, 2019 at 08:25:55AM -0400, Reinhard Tartler wrote:
> >Depends: libavcodec58 (= 7:4.1.1-2),
> > libavdevice58 (= 7:4.1.1-2), libavfilter7 (= 7:4.1.1-2), libavformat58 (=
> > 7:4.1.1-2), libavresample4 (= 7:4.1.1-2), libavutil56 (= 7:4.1.1-2),
> libc6
> > (>= 2.14), libpostproc55 (= 7:4.1.1-2), libswresample3 (= 7:4.1.1-2),
> > libswscale5 (= 7:4.1.1-2)
> >  Suggests: ffmpeg-doc
>
> You might want to add a Suggests on ffplay, as well.
>

Good idea, done.

The changes are in the 'master' branch of our packaging repository now.
Unfortunately, we missed the Debian freeze. Not sure if this is worth
asking for a freeze exception.

What do you guys think?

-- 
regards,
Reinhard

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Reinhard Tartler]

On Tue, Mar 12, 2019 at 1:49 PM Josh Triplett  wrote:

> On Tue, Mar 12, 2019 at 08:25:55AM -0400, Reinhard Tartler wrote:
> >Depends: libavcodec58 (= 7:4.1.1-2),
> > libavdevice58 (= 7:4.1.1-2), libavfilter7 (= 7:4.1.1-2), libavformat58 (=
> > 7:4.1.1-2), libavresample4 (= 7:4.1.1-2), libavutil56 (= 7:4.1.1-2),
> libc6
> > (>= 2.14), libpostproc55 (= 7:4.1.1-2), libswresample3 (= 7:4.1.1-2),
> > libswscale5 (= 7:4.1.1-2)
> >  Suggests: ffmpeg-doc
>
> You might want to add a Suggests on ffplay, as well.
>

Good idea, done.

The changes are in the 'master' branch of our packaging repository now.
Unfortunately, we missed the Debian freeze. Not sure if this is worth
asking for a freeze exception.

What do you guys think?

-- 
regards,
Reinhard

Bug#924257: docker.io: Misses to install some golang packages

[Reinhard Tartler]

Control: tag -1 patch

On 3/10/19 9:32 PM, Arnaud Rebillout wrote:

>>
>> As far as I understand the packaging, it seems that all of them could be 
>> easily added to
>> https://sources.debian.org/src/docker.io/18.09.1+dfsg1-5/debian/golang-github-docker-docker-dev.install
>>
>> Is this assumption right? Are there compelling reasons against doing that?
> 
> I think you're correct, you should give it a try, and if it works feel
> free to commit on the docker.io salsa repo.
> [...]

Hi Arnaud,

thank you very much for your detailed explanation, while surprising, it does 
help with the understanding of this source package significantly.

I've implemented the change and confirmed that the attached patch does allow 
github.com/openstack/imagebuilder to be built successfully. As suggested, I've 
tried to push to salsa, but it seems I'm not permissioned to do so (docker.io 
is not under the go-team umbrella):

  $ git push 
  GitLab: You are not allowed to push code to this project.
  fatal: Could not read from remote repository.

Would you be able to upload the patch to experimental anytime soon? If it 
helped, I'd be happy to upload this patch as an NMU to experimental myself. 
Please let me know what works for you best.

Cheers,
-rt
From 4abbd5b15e0735443cf8ad54165ab054dcab6f14 Mon Sep 17 00:00:00 2001
From: Reinhard Tartler 
Date: Tue, 12 Mar 2019 18:53:36 -0400
Subject: [PATCH] github-golang-docker-docker-dev: add missing sources

While working on the package 'golang-github-openshift-imagebuilder', it
turns out that some sources that are contained in the docker.io source
package were left out at installation time. This commit includes
some sources that allow golang-github-openshift-imagebuilder to be
built.

Closes: #924257
---
 debian/golang-github-docker-docker-dev.install | 9 +
 1 file changed, 9 insertions(+)

diff --git a/debian/golang-github-docker-docker-dev.install b/debian/golang-github-docker-docker-dev.install
index b5cdcebe..fc6c5861 100644
--- a/debian/golang-github-docker-docker-dev.install
+++ b/debian/golang-github-docker-docker-dev.install
@@ -11,9 +11,12 @@
 ## Engine
 engine/dockerversionusr/share/gocode/src/github.com/docker/docker/
 .gopath/src/github.com/docker/docker/apiusr/share/gocode/src/github.com/docker/docker/
+.gopath/src/github.com/docker/docker/builderusr/share/gocode/src/github.com/docker/docker/
 .gopath/src/github.com/docker/docker/cliusr/share/gocode/src/github.com/docker/docker/
 .gopath/src/github.com/docker/docker/client usr/share/gocode/src/github.com/docker/docker/
+.gopath/src/github.com/docker/docker/container  usr/share/gocode/src/github.com/docker/docker/
 .gopath/src/github.com/docker/docker/errdefsusr/share/gocode/src/github.com/docker/docker/
+.gopath/src/github.com/docker/docker/image  usr/share/gocode/src/github.com/docker/docker/
 .gopath/src/github.com/docker/docker/opts   usr/share/gocode/src/github.com/docker/docker/
 .gopath/src/github.com/docker/docker/pkgusr/share/gocode/src/github.com/docker/docker/
 .gopath/src/github.com/docker/docker/reference  usr/share/gocode/src/github.com/docker/docker/
@@ -31,6 +34,10 @@ engine/dockerversionusr/share/gocode/src/github.
 .gopath/src/github.com/docker/libnetwork/typesusr/share/gocode/src/github.com/docker/libnetwork/
 
 
+## go-metrics
+.gopath/src/github.com/docker/go-metricsusr/share/gocode/src/github.com/docker/go-metrics
+
+
 ## Sub-vendoring:
 engine/vendor/github.com/containerd/continuity/driverusr/share/gocode/src/github.com/docker/docker/vendor/github.com/containerd/continuity/
 engine/vendor/github.com/containerd/continuity/pathdriverusr/share/gocode/src/github.com/docker/docker/vendor/github.com/containerd/continuity/
@@ -39,3 +46,5 @@ engine/vendor/github.com/Nvveen/Gottyusr/share/gocode/sr
 
 distribution/reference   usr/share/gocode/src/github.com/docker/docker/vendor/github.com/docker/distribution/
 distribution/digestset   usr/share/gocode/src/github.com/docker/docker/vendor/github.com/docker/distribution/
+
+cli/vendor/github.com/moby/buildkit/ usr/share/gocode/src/github.com/moby/
-- 
2.11.0

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Reinhard Tartler]

On Sun, Mar 10, 2019 at 9:36 PM Carl Eugen Hoyos  wrote:

> > What might work is disabling the avdevice outdev AND
> > moving 'ffplay' to its own binary package.
>
> Before suggesting this, I would prefer the OP to test. I
> still do not entirely believe that this fixes his issue.
>
>
There is a good chance that the OP did not get this message, because
debbugs does not automatically subscribe the original submitter. One has to
exlicitly use the nn-submit...@bugs.debian.org alias or include his
email address explicitly.

I've went ahead and implemented the change (passing in
--disable-outdev=sdl2 as you suggested, and moving ffplay into its own
binary package)

With this patch, the ffmpeg binary package has a depends line like this:






 Package: ffmpeg

 Version: 7:4.1.1-2

   Architecture: amd64

   Maintainer:
Debian Multimedia Maintainers 

 Installed-Size: 1808

   Depends: libavcodec58 (= 7:4.1.1-2),
libavdevice58 (= 7:4.1.1-2), libavfilter7 (= 7:4.1.1-2), libavformat58 (=
7:4.1.1-2), libavresample4 (= 7:4.1.1-2), libavutil56 (= 7:4.1.1-2), libc6
(>= 2.14), libpostproc55 (= 7:4.1.1-2), libswresample3 (= 7:4.1.1-2),
libswscale5 (= 7:4.1.1-2)
 Suggests: ffmpeg-doc

   Breaks: libav-tools (<< 6:12~~), qt-faststart (<<
7:2.7.1-3~), winff (<< 1.5.5-5~)
   Replaces: libav-tools (<<
6:12~~), qt-faststart (<< 7:2.7.1-3~)
   Section:
video






Note that there is a dependency on libavdevice58, but not on SDL.





The 'ffplay' binary package has a depends line that looks like this:






 Package: ffplay
 Source: ffmpeg
 Version: 7:4.1.1-2
 Architecture: amd64
 Maintainer: Debian Multimedia Maintainers <
debian-multimedia@lists.debian.org>
 Installed-Size: 226

   Depends: libavcodec58 (= 7:4.1.1-2), libavdevice58 (=
7:4.1.1-2), libavfilter7 (= 7:4.1.1-2), libavformat58 (= 7:4.1.1-2),
libavresample4 (= 7:4.1.1-2), libavutil56 (= 7:4.1.1-2), libc6 (>= 2.14),
libpostproc55 (= 7:4.1.1-2), libsdl2-2.0-0 (>= 2.0.9), libswresample3 (=
7:4.1.1-2), libswscale5 (= 7:4.1.1-2), ffmpeg
 Suggests: ffmpeg-doc

 Breaks: ffmpeg (<< 7:4.1.1-2~), libav-tools (<<
6:12~~), qt-faststart (<< 7:2.7.1-3~), winff (<< 1.5.5-5~)
 Replaces: ffmpeg (<<
7:4.1.1-2~), libav-tools (<< 6:12~~), qt-faststart (<< 7:2.7.1-3~)

Section:
video






Note that this includes both libavdevice58 as well as libsdl2-2.






I think this should address the issue. Any objections to this approach?


-- 
regards,
Reinhard

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Reinhard Tartler]

On Sun, Mar 10, 2019 at 9:36 PM Carl Eugen Hoyos  wrote:

> > What might work is disabling the avdevice outdev AND
> > moving 'ffplay' to its own binary package.
>
> Before suggesting this, I would prefer the OP to test. I
> still do not entirely believe that this fixes his issue.
>
>
There is a good chance that the OP did not get this message, because
debbugs does not automatically subscribe the original submitter. One has to
exlicitly use the nn-submit...@bugs.debian.org alias or include his
email address explicitly.

I've went ahead and implemented the change (passing in
--disable-outdev=sdl2 as you suggested, and moving ffplay into its own
binary package)

With this patch, the ffmpeg binary package has a depends line like this:






 Package: ffmpeg

 Version: 7:4.1.1-2

   Architecture: amd64

   Maintainer:
Debian Multimedia Maintainers 

 Installed-Size: 1808

   Depends: libavcodec58 (= 7:4.1.1-2),
libavdevice58 (= 7:4.1.1-2), libavfilter7 (= 7:4.1.1-2), libavformat58 (=
7:4.1.1-2), libavresample4 (= 7:4.1.1-2), libavutil56 (= 7:4.1.1-2), libc6
(>= 2.14), libpostproc55 (= 7:4.1.1-2), libswresample3 (= 7:4.1.1-2),
libswscale5 (= 7:4.1.1-2)
 Suggests: ffmpeg-doc

   Breaks: libav-tools (<< 6:12~~), qt-faststart (<<
7:2.7.1-3~), winff (<< 1.5.5-5~)
   Replaces: libav-tools (<<
6:12~~), qt-faststart (<< 7:2.7.1-3~)
   Section:
video






Note that there is a dependency on libavdevice58, but not on SDL.





The 'ffplay' binary package has a depends line that looks like this:






 Package: ffplay
 Source: ffmpeg
 Version: 7:4.1.1-2
 Architecture: amd64
 Maintainer: Debian Multimedia Maintainers <
debian-multime...@lists.debian.org>
 Installed-Size: 226

   Depends: libavcodec58 (= 7:4.1.1-2), libavdevice58 (=
7:4.1.1-2), libavfilter7 (= 7:4.1.1-2), libavformat58 (= 7:4.1.1-2),
libavresample4 (= 7:4.1.1-2), libavutil56 (= 7:4.1.1-2), libc6 (>= 2.14),
libpostproc55 (= 7:4.1.1-2), libsdl2-2.0-0 (>= 2.0.9), libswresample3 (=
7:4.1.1-2), libswscale5 (= 7:4.1.1-2), ffmpeg
 Suggests: ffmpeg-doc

 Breaks: ffmpeg (<< 7:4.1.1-2~), libav-tools (<<
6:12~~), qt-faststart (<< 7:2.7.1-3~), winff (<< 1.5.5-5~)
 Replaces: ffmpeg (<<
7:4.1.1-2~), libav-tools (<< 6:12~~), qt-faststart (<< 7:2.7.1-3~)

Section:
video






Note that this includes both libavdevice58 as well as libsdl2-2.






I think this should address the issue. Any objections to this approach?


-- 
regards,
Reinhard

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Reinhard Tartler]

On Sun, Mar 10, 2019 at 6:57 PM Carl Eugen Hoyos  wrote:

> 2019-03-10 23:21 GMT+01:00, Reinhard Tartler :
> > On Sat, Mar 9, 2019 at 2:51 PM Carl Eugen Hoyos 
> wrote:
> >
> >> Could you test the configure option "--disable-outdev=sdl2"?
> >> Your report indicates it should fix your issue, I am not convinced but
> >> if it fixes your issue, Debian should consider using it as the device
> >> is mostly a (cheap) debug feature.
>
> > Wouldn't that video break playback in 'ffplay'?
>
> Can you elaborate why you think so?
>

By looking at
https://sources.debian.org/src/ffmpeg/7:4.1.1-1/fftools/ffplay.c/, I see
plenty of references to SDL, many of which aren't guarded by #ifdefs. Looks
like SDL2 is a hard dependency for a functional ffplay.


> > Can you elaborate what makes you think so?
>
> Iirc, I was the only one speaking against its removal.
>

You mean dropping ffplay altogether? - I am having a hard time parsing that
sentence.

> But given that your avconv project never contained an sdl output
> device I wonder what your expertise is here?
>
>
I believe we may mis-communicating here. AFAIUI, the original poster wanted
to make SDL an optional dependency. Even if the debian package was compiled
with '--disable-outdev=sdl2', wouldn't the 'ffmpeg' binary package still
continue to depend on sdl2 libraries? - In that case we haven't won
anything by this. I guess the debian package would in addition have to pass
the --disable-sdl2 switch to configure, which to my understanding would
prevent 'ffplay' from being compiled. I would consider that a regression.

What might work is disabling the avdevice outdev AND moving 'ffplay' to its
own binary package.

-- 
regards,
Reinhard

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Reinhard Tartler]

On Sun, Mar 10, 2019 at 6:57 PM Carl Eugen Hoyos  wrote:

> 2019-03-10 23:21 GMT+01:00, Reinhard Tartler :
> > On Sat, Mar 9, 2019 at 2:51 PM Carl Eugen Hoyos 
> wrote:
> >
> >> Could you test the configure option "--disable-outdev=sdl2"?
> >> Your report indicates it should fix your issue, I am not convinced but
> >> if it fixes your issue, Debian should consider using it as the device
> >> is mostly a (cheap) debug feature.
>
> > Wouldn't that video break playback in 'ffplay'?
>
> Can you elaborate why you think so?
>

By looking at
https://sources.debian.org/src/ffmpeg/7:4.1.1-1/fftools/ffplay.c/, I see
plenty of references to SDL, many of which aren't guarded by #ifdefs. Looks
like SDL2 is a hard dependency for a functional ffplay.


> > Can you elaborate what makes you think so?
>
> Iirc, I was the only one speaking against its removal.
>

You mean dropping ffplay altogether? - I am having a hard time parsing that
sentence.

> But given that your avconv project never contained an sdl output
> device I wonder what your expertise is here?
>
>
I believe we may mis-communicating here. AFAIUI, the original poster wanted
to make SDL an optional dependency. Even if the debian package was compiled
with '--disable-outdev=sdl2', wouldn't the 'ffmpeg' binary package still
continue to depend on sdl2 libraries? - In that case we haven't won
anything by this. I guess the debian package would in addition have to pass
the --disable-sdl2 switch to configure, which to my understanding would
prevent 'ffplay' from being compiled. I would consider that a regression.

What might work is disabling the avdevice outdev AND moving 'ffplay' to its
own binary package.

-- 
regards,
Reinhard

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Reinhard Tartler]

On Sat, Mar 9, 2019 at 2:51 PM Carl Eugen Hoyos  wrote:

> Hi!
>
> Could you test the configure option "--disable-outdev=sdl2"?
> Your report indicates it should fix your issue, I am not convinced but
> if it fixes your issue, Debian should consider using it as the device
> is mostly a (cheap) debug feature.
>
> Please report back, Carl Eugen
>
>
Wouldn't that video break playback in 'ffplay'? - at the very least, it
would break the "SDL2 output device" in libavdevice.

I'm not sure if I'd agree with that being a "cheap debug [only] feature".
Can you elaborate what makes you think so?

-- 
regards,
Reinhard

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Reinhard Tartler]

On Sat, Mar 9, 2019 at 2:51 PM Carl Eugen Hoyos  wrote:

> Hi!
>
> Could you test the configure option "--disable-outdev=sdl2"?
> Your report indicates it should fix your issue, I am not convinced but
> if it fixes your issue, Debian should consider using it as the device
> is mostly a (cheap) debug feature.
>
> Please report back, Carl Eugen
>
>
Wouldn't that video break playback in 'ffplay'? - at the very least, it
would break the "SDL2 output device" in libavdevice.

I'm not sure if I'd agree with that being a "cheap debug [only] feature".
Can you elaborate what makes you think so?

-- 
regards,
Reinhard

Re: RFS: golang-github-spkg-bom

[Reinhard Tartler]

Thanks, package looks good, I've just uploaded it.

On Sun, Mar 10, 2019 at 3:27 PM Dawid Dziurla  wrote:

> Sorry for your inconvenience. I've already pushed a fix for this I believe.
>
> niedz., 10 mar 2019 o 20:06 Reinhard Tartler 
> napisał(a):
> >
> > I've been struggling with getting your package built with gbp.
> >
> > It seems that you are using non-standard branch names. I could
> work-around it in gbp-clone by using this command:
> >
> > $ gbp clone --debian-branch=debian/sid
> salsa:go-team/packages/golang-github-spkg-bom
> >
> >
> > To build it, I also had to edit 'debian/gbp.conf' to have this stanza:
> >
> > [DEFAULT]
> > debian-branch=debian/sid
> >
> >
> >
> > However, now I'm experiencing this error:
> >
> > $ gbp buildpackage -S -d
> > gbp:error: upstream/0.0_git20160624.59b7046 is not a valid treeish
> >
> >
> >
> > At this point, I give up with this package. Sorry. I would have liked to
> sponsor you but I've run out of time, most of which was wasted on such
> technicalities.
> >
> >
> > On Sun, Mar 10, 2019 at 2:18 PM Dawid Dziurla 
> wrote:
> >>
> >> Package repository:
> >>  https://salsa.debian.org/go-team/packages/golang-github-spkg-bom
> >>
> >
> >
> > --
> > regards,
> > Reinhard
>


-- 
regards,
Reinhard

Accepted keepassx 2.0.3-3 (source) into unstable

[Reinhard Tartler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 10 Mar 2019 15:18:52 -0400
Source: keepassx
Binary: keepassx
Architecture: source
Version: 2.0.3-3
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group 
Changed-By: Reinhard Tartler 
Description:
 keepassx   - Cross Platform Password Manager
Changes:
 keepassx (2.0.3-3) unstable; urgency=medium
 .
   * Orphan package, set maintainer to Debian QA Group
Checksums-Sha1:
 45b659cdd5a7314865258f691f766444c5f8dad2 1893 keepassx_2.0.3-3.dsc
 c8c0a93a9a8f08b5c0a0ae254af35ff37312919e 84376 keepassx_2.0.3-3.debian.tar.xz
 1596eafff58b299ee4a7e699dc971cf4febfed89 5995 keepassx_2.0.3-3_source.buildinfo
Checksums-Sha256:
 4779655a6c05498c6d5471e8fd722bed847af77d606761e183b685cba853d769 1893 
keepassx_2.0.3-3.dsc
 c2a2857f7aa079ba92ec9683348a09f36c012e61dcd279e000b7f052d0060560 84376 
keepassx_2.0.3-3.debian.tar.xz
 f7d4280486ce949aa0ec51b188d69e3a49ffac5fd8f996cc4585ab33826810b7 5995 
keepassx_2.0.3-3_source.buildinfo
Files:
 c6b9e8bc778d649785c5073249609018 1893 utils optional keepassx_2.0.3-3.dsc
 ce427532217364779dab6aa5cdff22f8 84376 utils optional 
keepassx_2.0.3-3.debian.tar.xz
 f6aaeb21f9c62c8beedf655526e8bb07 5995 utils optional 
keepassx_2.0.3-3_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE6n5rckvJ+/LRcetya3IL6cXPbZ4FAlyFY+EACgkQa3IL6cXP
bZ5BnQ//RJjbmZqg3l5VV5iTFRTTT7nbn+pgg/CwxtQ2RU6uBwTeTzXkFYP5JHGt
WSiDhj7+H2pS9/KliIwrOsQ6XOWN/Z6h2ktJnaFE9Wv0XfSqq90WAu4qVvA4/KfL
ZSrDYMY+7TTgGEoPoWiXfGTHKdaSvcPLOAz2zdc0hWpiwwbJWMqHERnY4nRvST7B
HncAoA82X99tS6QmeHtEEoALaSRHNqvVn1SJZ2y2YuCa6Ib5zho9pVEl3ZiZK9jQ
hirpMeqkDd4tY7wQxH4w27lI8S31ZVR0uSQKbNwyW8AaS0GF2/9qU/F7xMO0yrri
fR5MkVatMslokH0SUg01BAitekoW3SDapQM1+R2IPuXrbVW+sR59DGD0+PEOsW1V
R28IT55spuABoV/yxDuRh2UFN777ZDt5Q+oLFI9VNVAQyYcrRrpRLUk7INs2A5kI
O7WEmva3uyg+XVDPilfz2UNNhKPzR7r/ZlUPXwav30Rv2vgJAsVHqt3oQK6xg5kv
RBR5f6TrcDvRhoXljFPOiVqSPaLW+5+roQKB0NCLFqxlyIOnmcTifPh+uuWjoI9D
0TNYgbTGwpvZUnOY4fZSInmN0+IC79dNoiMM2ZEURienxNzcwaAqlolJksjglfLL
z4MhnLWrt8HRhaRt1pPL6ryC05CTA+hxZByLJ5eoq4om4oytLGU=
=XqkV
-END PGP SIGNATURE-

Bug#924270: O: keepassx -- Cross Platform Password Manager

[Reinhard Tartler]

Package: wnpp
Severity: normal

Keepassx is a graphical password manager, using the Qt4 toolkit. I'm no
longer using this package and have personally switched to
'password-store'.  Unfortunately, I've also failed to get a response
from upstream from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920616 - which
recommends to replace keepassx with keepassxc, a community fork,
possibly because of unresponsive upstream.

I am undecided whether or not this package should be included in Debian
10 (aka buster). It clearly is useful to many people, but its long-term
maintenance is unclear.

I'd encourage people interested in picking up this package to coordinate
with Julian Klode (CC'ed), the Debian keepassxc maintainer.

Best,
-rt

Bug#924270: O: keepassx -- Cross Platform Password Manager

[Reinhard Tartler]

Package: wnpp
Severity: normal

Keepassx is a graphical password manager, using the Qt4 toolkit. I'm no
longer using this package and have personally switched to
'password-store'.  Unfortunately, I've also failed to get a response
from upstream from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920616 - which
recommends to replace keepassx with keepassxc, a community fork,
possibly because of unresponsive upstream.

I am undecided whether or not this package should be included in Debian
10 (aka buster). It clearly is useful to many people, but its long-term
maintenance is unclear.

I'd encourage people interested in picking up this package to coordinate
with Julian Klode (CC'ed), the Debian keepassxc maintainer.

Best,
-rt

Bug#924270: O: keepassx -- Cross Platform Password Manager

[Reinhard Tartler]

Package: wnpp
Severity: normal

Keepassx is a graphical password manager, using the Qt4 toolkit. I'm no
longer using this package and have personally switched to
'password-store'.  Unfortunately, I've also failed to get a response
from upstream from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920616 - which
recommends to replace keepassx with keepassxc, a community fork,
possibly because of unresponsive upstream.

I am undecided whether or not this package should be included in Debian
10 (aka buster). It clearly is useful to many people, but its long-term
maintenance is unclear.

I'd encourage people interested in picking up this package to coordinate
with Julian Klode (CC'ed), the Debian keepassxc maintainer.

Best,
-rt

Re: RFS: golang-github-spkg-bom

[Reinhard Tartler]

I've been struggling with getting your package built with gbp.

It seems that you are using non-standard branch names. I could work-around
it in gbp-clone by using this command:

$ gbp clone --debian-branch=debian/sid
salsa:go-team/packages/golang-github-spkg-bom


To build it, I also had to edit 'debian/gbp.conf' to have this stanza:

[DEFAULT]
debian-branch=debian/sid



However, now I'm experiencing this error:

$ gbp buildpackage -S -d
gbp:error: upstream/0.0_git20160624.59b7046 is not a valid treeish



At this point, I give up with this package. Sorry. I would have liked to
sponsor you but I've run out of time, most of which was wasted on such
technicalities.


On Sun, Mar 10, 2019 at 2:18 PM Dawid Dziurla  wrote:

> Package repository:
>  https://salsa.debian.org/go-team/packages/golang-github-spkg-bom
>
>

-- 
regards,
Reinhard

Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys

[Reinhard Tartler]

>
> On Mon, Jan 7, 2019, 16:58 Chris Wilson >
>>> Hi Reinhard,
>>>
>>> If I make the workaround suggested on this thread
>>>  (change
>>> SECLEVEL to 1 in /etc/ssl/openssl.cnf) then test/basicserver passes again.
>>> This is at least a good start, so that users who don't want to replace
>>> their certificates have a workaround. I think I'll need to modify the CA
>>> scripts that generate certificates so that they produce 2048-bit keys that
>>> do not need this workaround, and document it or catch and improve the error
>>> message.
>>>
>>>
Any progress on updating the CA scripts that generate certificates so that
they produce 2048-bit keys?

I've updated the package to git20180819.g2f5b556, but am still experiencing
a test failure:

make[1]: Leaving directory '/<>/test/basicserver'
TEST: test/basicserver
Killing any running daemons...
Removing old test files...
chmod: cannot access 'testfiles': No such file or directory
Copying new test files...
NOTICE:  Running test basicserver in debug mode...
INFO:Starting server: ./_test --test-daemon-args= srv1
testfiles/srv1.conf
Waiting for server to die (pid 16575): . done.
INFO:Starting server: ./_test --test-daemon-args= srv2
testfiles/srv2.conf
Waiting for server to die (pid 16579): . done.
INFO:Starting server: ./_test --test-daemon-args= srv3
testfiles/srv3.conf
ERROR:    TEST FAILURE: Condition [ServerIsAlive(pid)] failed at
test/basicserver/testbasicserver.cpp:628
ERROR:    TEST FAILURE: Condition [HUPServer(pid)] failed at
test/basicserver/testbasicserver.cpp:631
ERROR:    TEST FAILURE: Condition [ServerIsAlive(pid)] failed at
test/basicserver/testbasicserver.cpp:633
ERROR:   SSL or crypto error: loading certificates from
testfiles/clientCerts.pem: error:140AB18F:SSL
routines:SSL_CTX_use_certificate:ee key too small
WARNING: Exception thrown: ServerException(TLSLoadCertificatesFailed) at
lib/server/TLSContext.cpp(93)
FAILED: Exception caught: TLSLoadCertificatesFailed



-- 
regards,
Reinhard

Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys

[Reinhard Tartler]

>
> On Mon, Jan 7, 2019, 16:58 Chris Wilson >
>>> Hi Reinhard,
>>>
>>> If I make the workaround suggested on this thread
>>>  (change
>>> SECLEVEL to 1 in /etc/ssl/openssl.cnf) then test/basicserver passes again.
>>> This is at least a good start, so that users who don't want to replace
>>> their certificates have a workaround. I think I'll need to modify the CA
>>> scripts that generate certificates so that they produce 2048-bit keys that
>>> do not need this workaround, and document it or catch and improve the error
>>> message.
>>>
>>>
Any progress on updating the CA scripts that generate certificates so that
they produce 2048-bit keys?

I've updated the package to git20180819.g2f5b556, but am still experiencing
a test failure:

make[1]: Leaving directory '/<>/test/basicserver'
TEST: test/basicserver
Killing any running daemons...
Removing old test files...
chmod: cannot access 'testfiles': No such file or directory
Copying new test files...
NOTICE:  Running test basicserver in debug mode...
INFO:Starting server: ./_test --test-daemon-args= srv1
testfiles/srv1.conf
Waiting for server to die (pid 16575): . done.
INFO:Starting server: ./_test --test-daemon-args= srv2
testfiles/srv2.conf
Waiting for server to die (pid 16579): . done.
INFO:Starting server: ./_test --test-daemon-args= srv3
testfiles/srv3.conf
ERROR:    TEST FAILURE: Condition [ServerIsAlive(pid)] failed at
test/basicserver/testbasicserver.cpp:628
ERROR:    TEST FAILURE: Condition [HUPServer(pid)] failed at
test/basicserver/testbasicserver.cpp:631
ERROR:    TEST FAILURE: Condition [ServerIsAlive(pid)] failed at
test/basicserver/testbasicserver.cpp:633
ERROR:   SSL or crypto error: loading certificates from
testfiles/clientCerts.pem: error:140AB18F:SSL
routines:SSL_CTX_use_certificate:ee key too small
WARNING: Exception thrown: ServerException(TLSLoadCertificatesFailed) at
lib/server/TLSContext.cpp(93)
FAILED: Exception caught: TLSLoadCertificatesFailed



-- 
regards,
Reinhard

Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys

[Reinhard Tartler]

>
> On Mon, Jan 7, 2019, 16:58 Chris Wilson >
>>> Hi Reinhard,
>>>
>>> If I make the workaround suggested on this thread
>>>  (change
>>> SECLEVEL to 1 in /etc/ssl/openssl.cnf) then test/basicserver passes again.
>>> This is at least a good start, so that users who don't want to replace
>>> their certificates have a workaround. I think I'll need to modify the CA
>>> scripts that generate certificates so that they produce 2048-bit keys that
>>> do not need this workaround, and document it or catch and improve the error
>>> message.
>>>
>>>
Any progress on updating the CA scripts that generate certificates so that
they produce 2048-bit keys?

I've updated the package to git20180819.g2f5b556, but am still experiencing
a test failure:

make[1]: Leaving directory '/<>/test/basicserver'
TEST: test/basicserver
Killing any running daemons...
Removing old test files...
chmod: cannot access 'testfiles': No such file or directory
Copying new test files...
NOTICE:  Running test basicserver in debug mode...
INFO:Starting server: ./_test --test-daemon-args= srv1
testfiles/srv1.conf
Waiting for server to die (pid 16575): . done.
INFO:Starting server: ./_test --test-daemon-args= srv2
testfiles/srv2.conf
Waiting for server to die (pid 16579): . done.
INFO:Starting server: ./_test --test-daemon-args= srv3
testfiles/srv3.conf
ERROR:    TEST FAILURE: Condition [ServerIsAlive(pid)] failed at
test/basicserver/testbasicserver.cpp:628
ERROR:    TEST FAILURE: Condition [HUPServer(pid)] failed at
test/basicserver/testbasicserver.cpp:631
ERROR:    TEST FAILURE: Condition [ServerIsAlive(pid)] failed at
test/basicserver/testbasicserver.cpp:633
ERROR:   SSL or crypto error: loading certificates from
testfiles/clientCerts.pem: error:140AB18F:SSL
routines:SSL_CTX_use_certificate:ee key too small
WARNING: Exception thrown: ServerException(TLSLoadCertificatesFailed) at
lib/server/TLSContext.cpp(93)
FAILED: Exception caught: TLSLoadCertificatesFailed



-- 
regards,
Reinhard

Bug#924257: docker.io: Misses to install some golang packages

[Reinhard Tartler]

Source: docker.io
Severity: normal
Control: block 923300 by -1

While working on the package 'golang-github-openshift-imagebuilder', I
was running into compilation errors, more specifically, unresolved
dependencies during the build:

   dh_auto_build -O--buildsystem=golang
cd obj-x86_64-linux-gnu && go install 
-gcflags=all=\"-trimpath=/<>/golang-github-openshift-imagebuilder-1.0\+git20190308.705fe92/obj-x86_64-linux-gnu/src\"
 
-asmflags=all=\"-trimpath=/<>/golang-github-openshift-imagebuilder-1.0\+git20190308.705fe92/obj-x86_64-linux-gnu/src\"
 -v -p 4 github.com/openshift/imagebuilder 
github.com/openshift/imagebuilder/cmd/imagebuilder 
github.com/openshift/imagebuilder/dockerclient 
github.com/openshift/imagebuilder/dockerfile 
github.com/openshift/imagebuilder/dockerfile/command 
github.com/openshift/imagebuilder/dockerfile/parser 
github.com/openshift/imagebuilder/dockerfile/parser/dumper 
github.com/openshift/imagebuilder/imageprogress 
github.com/openshift/imagebuilder/signal 
github.com/openshift/imagebuilder/strslice
src/github.com/openshift/imagebuilder/dockerfile/builder.go:15:2: cannot find 
package "github.com/docker/docker/builder" in any of:
/usr/lib/go-1.11/src/github.com/docker/docker/builder (from $GOROOT)

/<>/golang-github-openshift-imagebuilder-1.0+git20190308.705fe92/obj-x86_64-linux-gnu/src/github.com/docker/docker/builder
 (from $GOPATH)
src/github.com/openshift/imagebuilder/dockerfile/builder.go:16:2: cannot find 
package "github.com/docker/docker/builder/dockerfile/command" in any of:

/usr/lib/go-1.11/src/github.com/docker/docker/builder/dockerfile/command (from 
$GOROOT)

/<>/golang-github-openshift-imagebuilder-1.0+git20190308.705fe92/obj-x86_64-linux-gnu/src/github.com/docker/docker/builder/dockerfile/command
 (from $GOPATH)
src/github.com/openshift/imagebuilder/dockerfile/builder.go:17:2: cannot find 
package "github.com/docker/docker/builder/dockerfile/parser" in any of:
/usr/lib/go-1.11/src/github.com/docker/docker/builder/dockerfile/parser 
(from $GOROOT)

/<>/golang-github-openshift-imagebuilder-1.0+git20190308.705fe92/obj-x86_64-linux-gnu/src/github.com/docker/docker/builder/dockerfile/parser
 (from $GOPATH)
src/github.com/openshift/imagebuilder/dockerfile/builder.go:18:2: cannot find 
package "github.com/docker/docker/builder/fscache" in any of:
/usr/lib/go-1.11/src/github.com/docker/docker/builder/fscache (from 
$GOROOT)

/<>/golang-github-openshift-imagebuilder-1.0+git20190308.705fe92/obj-x86_64-linux-gnu/src/github.com/docker/docker/builder/fscache
 (from $GOPATH)
src/github.com/openshift/imagebuilder/dockerfile/builder.go:19:2: cannot find 
package "github.com/docker/docker/builder/remotecontext" in any of:
/usr/lib/go-1.11/src/github.com/docker/docker/builder/remotecontext 
(from $GOROOT)

/<>/golang-github-openshift-imagebuilder-1.0+git20190308.705fe92/obj-x86_64-linux-gnu/src/github.com/docker/docker/builder/remotecontext
 (from $GOPATH)
src/github.com/openshift/imagebuilder/dockerfile/containerbackend.go:10:2: 
cannot find package "github.com/docker/docker/container" in any of:
/usr/lib/go-1.11/src/github.com/docker/docker/container (from $GOROOT)

/<>/golang-github-openshift-imagebuilder-1.0+git20190308.705fe92/obj-x86_64-linux-gnu/src/github.com/docker/docker/container
 (from $GOPATH)
src/github.com/openshift/imagebuilder/dockerfile/dispatchers.go:25:2: cannot 
find package "github.com/docker/docker/image" in any of:
/usr/lib/go-1.11/src/github.com/docker/docker/image (from $GOROOT)

/<>/golang-github-openshift-imagebuilder-1.0+git20190308.705fe92/obj-x86_64-linux-gnu/src/github.com/docker/docker/image
 (from $GOPATH)
src/github.com/openshift/imagebuilder/dockerfile/metrics.go:4:2: cannot find 
package "github.com/docker/go-metrics" in any of:
/usr/lib/go-1.11/src/github.com/docker/go-metrics (from $GOROOT)

/<>/golang-github-openshift-imagebuilder-1.0+git20190308.705fe92/obj-x86_64-linux-gnu/src/github.com/docker/go-metrics
 (from $GOPATH)
src/github.com/openshift/imagebuilder/dockerfile/builder.go:26:2: cannot find 
package "github.com/moby/buildkit/session" in any of:
/usr/lib/go-1.11/src/github.com/moby/buildkit/session (from $GOROOT)

/<>/golang-github-openshift-imagebuilder-1.0+git20190308.705fe92/obj-x86_64-linux-gnu/src/github.com/moby/buildkit/session
 (from $GOPATH)
src/github.com/openshift/imagebuilder/dockerfile/clientsession.go:9:2: cannot 
find package "github.com/moby/buildkit/session/filesync" in any of:
/usr/lib/go-1.11/src/github.com/moby/buildkit/session/filesync (from 
$GOROOT)

/<>/golang-github-openshift-imagebuilder-1.0+git20190308.705fe92/obj-x86_64-linux-gnu/src/github.com/moby/buildkit/session/filesync
 (from $GOPATH)
dh_auto_build: cd obj-x86_64-linux-gnu && go install 

Bug#923722: golang-github-appc-cni: Please upgrade to new upstream 0.7.0-alpha1

[Reinhard Tartler]

Package: golang-github-appc-cni
Severity: wishlist

Hi,

Please update to new upstream version of 0.7.0-alpha1. I need it as a
build dependency of http://github.com/containers/buildah

In fact, I've done so locally, and would be happy to upload it as a Team
Upload. I was running into issues while doing so. Unlike the git
repositories created by the dh-make-golang tool, the git repository on
salsa at
https://salsa.debian.org/go-team/packages/golang-github-appc-cni does
not include full sources in the packaging branch. I am unfamiliar with
that workflow and it is inconsistent with how the vast majority of the
packages in the golang team are handled. I therefore decided to start
off from a 'dgit clone' created repository.

Dimtry, I wonder what your thoughts on this issue are.  Would you be OK
with switching the workflow? If not, could you please upload
0.7.0-alpha1 to experimental soon? Alternatively, I could upload the
package that I have locally to experimental, and leave updating salsa to
you (or someone else) whenever time permits.

What does the rest of the team think about competing git repository
workflows within the team? At least to me, this seems undesireable
because it prompts convesations like this (which I really don't enjoy
having).

Best,
-rt


-- System Information:
Debian Release: 9.7
  APT prefers stable
  APT policy: (500, 'stable'), (75, 'testing'), (50, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

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

[pkg-go] Bug#923722: golang-github-appc-cni: Please upgrade to new upstream 0.7.0-alpha1

[Reinhard Tartler]

Package: golang-github-appc-cni
Severity: wishlist

Hi,

Please update to new upstream version of 0.7.0-alpha1. I need it as a
build dependency of http://github.com/containers/buildah

In fact, I've done so locally, and would be happy to upload it as a Team
Upload. I was running into issues while doing so. Unlike the git
repositories created by the dh-make-golang tool, the git repository on
salsa at
https://salsa.debian.org/go-team/packages/golang-github-appc-cni does
not include full sources in the packaging branch. I am unfamiliar with
that workflow and it is inconsistent with how the vast majority of the
packages in the golang team are handled. I therefore decided to start
off from a 'dgit clone' created repository.

Dimtry, I wonder what your thoughts on this issue are.  Would you be OK
with switching the workflow? If not, could you please upload
0.7.0-alpha1 to experimental soon? Alternatively, I could upload the
package that I have locally to experimental, and leave updating salsa to
you (or someone else) whenever time permits.

What does the rest of the team think about competing git repository
workflows within the team? At least to me, this seems undesireable
because it prompts convesations like this (which I really don't enjoy
having).

Best,
-rt


-- System Information:
Debian Release: 9.7
  APT prefers stable
  APT policy: (500, 'stable'), (75, 'testing'), (50, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

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

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#923722: golang-github-appc-cni: Please upgrade to new upstream 0.7.0-alpha1

[Reinhard Tartler]

Package: golang-github-appc-cni
Severity: wishlist

Hi,

Please update to new upstream version of 0.7.0-alpha1. I need it as a
build dependency of http://github.com/containers/buildah

In fact, I've done so locally, and would be happy to upload it as a Team
Upload. I was running into issues while doing so. Unlike the git
repositories created by the dh-make-golang tool, the git repository on
salsa at
https://salsa.debian.org/go-team/packages/golang-github-appc-cni does
not include full sources in the packaging branch. I am unfamiliar with
that workflow and it is inconsistent with how the vast majority of the
packages in the golang team are handled. I therefore decided to start
off from a 'dgit clone' created repository.

Dimtry, I wonder what your thoughts on this issue are.  Would you be OK
with switching the workflow? If not, could you please upload
0.7.0-alpha1 to experimental soon? Alternatively, I could upload the
package that I have locally to experimental, and leave updating salsa to
you (or someone else) whenever time permits.

What does the rest of the team think about competing git repository
workflows within the team? At least to me, this seems undesireable
because it prompts convesations like this (which I really don't enjoy
having).

Best,
-rt


-- System Information:
Debian Release: 9.7
  APT prefers stable
  APT policy: (500, 'stable'), (75, 'testing'), (50, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

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

Bug#923300: ITP: golang-github-openshift-imagebuilder -- Builds Dockerfile using the Docker client

[Reinhard Tartler]

On Fri, Mar 1, 2019 at 9:26 AM Reinhard Tartler  wrote:

> That sounds really promising. I wonder how to implement it for this
> package.
>
> The yquake2 package uses gbp-buildpackage, pristine-tar and mk-origtargz,
> which I would love to continue using. Unlike yquake2, this package doesn't
> combine two seperate git repositories, but both sources come from the same
> upstream repository. Also, I would like the component to be placed in the
> subdirectory vendor/github.com/docker/docker, but to it seems to me that
> "components" may not include the "/" (or I missed how the "/" gets
> mangled).
> In conclusion, this means that "components" may only be placed at the
> top-level source directory.
>
> I guess what I can (should?) do is adjust the debian/copyright
> Files-Excluded field
> to exclude all entries but vendor/github.com/docker/docker, and use
> declare
> a 'vendor' component. Then I probably can use mk-origtargz to
> create both the "orig.tar.gz" as well as the "orig-vendor.tar.gz".
>
> That would, however, lead to a *very* elaborate Files-Excluded field.
>
>
I actually went ahead and implement this solution. The result can be seen at
https://salsa.debian.org/go-team/packages/golang-github-openshift-imagebuilder

comments / opinions welcome. I'll try using this package to build buildah
locally
before uploading to unstable.

best,
-rt
-- 
regards,
Reinhard

Bug#923300: ITP: golang-github-openshift-imagebuilder -- Builds Dockerfile using the Docker client

[Reinhard Tartler]

On Fri, Mar 1, 2019 at 9:26 AM Reinhard Tartler  wrote:

> That sounds really promising. I wonder how to implement it for this
> package.
>
> The yquake2 package uses gbp-buildpackage, pristine-tar and mk-origtargz,
> which I would love to continue using. Unlike yquake2, this package doesn't
> combine two seperate git repositories, but both sources come from the same
> upstream repository. Also, I would like the component to be placed in the
> subdirectory vendor/github.com/docker/docker, but to it seems to me that
> "components" may not include the "/" (or I missed how the "/" gets
> mangled).
> In conclusion, this means that "components" may only be placed at the
> top-level source directory.
>
> I guess what I can (should?) do is adjust the debian/copyright
> Files-Excluded field
> to exclude all entries but vendor/github.com/docker/docker, and use
> declare
> a 'vendor' component. Then I probably can use mk-origtargz to
> create both the "orig.tar.gz" as well as the "orig-vendor.tar.gz".
>
> That would, however, lead to a *very* elaborate Files-Excluded field.
>
>
I actually went ahead and implement this solution. The result can be seen at
https://salsa.debian.org/go-team/packages/golang-github-openshift-imagebuilder

comments / opinions welcome. I'll try using this package to build buildah
locally
before uploading to unstable.

best,
-rt
-- 
regards,
Reinhard

Re: Bug#923300: ITP: golang-github-openshift-imagebuilder -- Builds Dockerfile using the Docker client

[Reinhard Tartler]

On Fri, Mar 1, 2019 at 9:26 AM Reinhard Tartler  wrote:

> That sounds really promising. I wonder how to implement it for this
> package.
>
> The yquake2 package uses gbp-buildpackage, pristine-tar and mk-origtargz,
> which I would love to continue using. Unlike yquake2, this package doesn't
> combine two seperate git repositories, but both sources come from the same
> upstream repository. Also, I would like the component to be placed in the
> subdirectory vendor/github.com/docker/docker, but to it seems to me that
> "components" may not include the "/" (or I missed how the "/" gets
> mangled).
> In conclusion, this means that "components" may only be placed at the
> top-level source directory.
>
> I guess what I can (should?) do is adjust the debian/copyright
> Files-Excluded field
> to exclude all entries but vendor/github.com/docker/docker, and use
> declare
> a 'vendor' component. Then I probably can use mk-origtargz to
> create both the "orig.tar.gz" as well as the "orig-vendor.tar.gz".
>
> That would, however, lead to a *very* elaborate Files-Excluded field.
>
>
I actually went ahead and implement this solution. The result can be seen at
https://salsa.debian.org/go-team/packages/golang-github-openshift-imagebuilder

comments / opinions welcome. I'll try using this package to build buildah
locally
before uploading to unstable.

best,
-rt
-- 
regards,
Reinhard

Re: Bug#923300: ITP: golang-github-openshift-imagebuilder -- Builds Dockerfile using the Docker client

[Reinhard Tartler]

On Fri, Mar 1, 2019 at 9:26 AM Reinhard Tartler  wrote:

> That sounds really promising. I wonder how to implement it for this
> package.
>
> The yquake2 package uses gbp-buildpackage, pristine-tar and mk-origtargz,
> which I would love to continue using. Unlike yquake2, this package doesn't
> combine two seperate git repositories, but both sources come from the same
> upstream repository. Also, I would like the component to be placed in the
> subdirectory vendor/github.com/docker/docker, but to it seems to me that
> "components" may not include the "/" (or I missed how the "/" gets
> mangled).
> In conclusion, this means that "components" may only be placed at the
> top-level source directory.
>
> I guess what I can (should?) do is adjust the debian/copyright
> Files-Excluded field
> to exclude all entries but vendor/github.com/docker/docker, and use
> declare
> a 'vendor' component. Then I probably can use mk-origtargz to
> create both the "orig.tar.gz" as well as the "orig-vendor.tar.gz".
>
> That would, however, lead to a *very* elaborate Files-Excluded field.
>
>
I actually went ahead and implement this solution. The result can be seen at
https://salsa.debian.org/go-team/packages/golang-github-openshift-imagebuilder

comments / opinions welcome. I'll try using this package to build buildah
locally
before uploading to unstable.

best,
-rt
-- 
regards,
Reinhard

Bug#923300: ITP: golang-github-openshift-imagebuilder -- Builds Dockerfile using the Docker client

[Reinhard Tartler]

That sounds really promising. I wonder how to implement it for this package.

The yquake2 package uses gbp-buildpackage, pristine-tar and mk-origtargz,
which I would love to continue using. Unlike yquake2, this package doesn't
combine two seperate git repositories, but both sources come from the same
upstream repository. Also, I would like the component to be placed in the
subdirectory vendor/github.com/docker/docker, but to it seems to me that
"components" may not include the "/" (or I missed how the "/" gets mangled).
In conclusion, this means that "components" may only be placed at the
top-level source directory.

I guess what I can (should?) do is adjust the debian/copyright
Files-Excluded field
to exclude all entries but vendor/github.com/docker/docker, and use declare
a 'vendor' component. Then I probably can use mk-origtargz to
create both the "orig.tar.gz" as well as the "orig-vendor.tar.gz".

That would, however, lead to a *very* elaborate Files-Excluded field.

Does this make sense, or is there a simpler solution?

The llvm-toolchain-7 example does not use gbp-buildpackage or pristine-tar.
Instead
they apparently have a script that generates all tarballs:
https://sources.debian.org/src/llvm-toolchain-7/1:7.0.1-8/debian/orig-tar.sh/
I guess having a dedicated script such as this means not being able to
use mk-origtargz. I would find that a bit unfortunate, because I'd hate this
package to be a snowflake in the go-lang packaging team. Or do we already
have similar snowflakes?

what does the team think which approach is better?


-rt

On Fri, Mar 1, 2019 at 2:55 AM Simon McVittie  wrote:

>
> You could consider using a multiple-.orig-tarball package in 3.0
> (quilt) format? See for example yquake2 (a relatively simple
> example which bundles together https://github.com/yquake2/yquake2 and
> https://github.com/yquake2/ctf) or llvm-toolchain-7 (a more elaborate
> example with multiple subprojects).
>
> smcv
>
>

-- 
regards,
Reinhard

Bug#923300: ITP: golang-github-openshift-imagebuilder -- Builds Dockerfile using the Docker client

[Reinhard Tartler]

That sounds really promising. I wonder how to implement it for this package.

The yquake2 package uses gbp-buildpackage, pristine-tar and mk-origtargz,
which I would love to continue using. Unlike yquake2, this package doesn't
combine two seperate git repositories, but both sources come from the same
upstream repository. Also, I would like the component to be placed in the
subdirectory vendor/github.com/docker/docker, but to it seems to me that
"components" may not include the "/" (or I missed how the "/" gets mangled).
In conclusion, this means that "components" may only be placed at the
top-level source directory.

I guess what I can (should?) do is adjust the debian/copyright
Files-Excluded field
to exclude all entries but vendor/github.com/docker/docker, and use declare
a 'vendor' component. Then I probably can use mk-origtargz to
create both the "orig.tar.gz" as well as the "orig-vendor.tar.gz".

That would, however, lead to a *very* elaborate Files-Excluded field.

Does this make sense, or is there a simpler solution?

The llvm-toolchain-7 example does not use gbp-buildpackage or pristine-tar.
Instead
they apparently have a script that generates all tarballs:
https://sources.debian.org/src/llvm-toolchain-7/1:7.0.1-8/debian/orig-tar.sh/
I guess having a dedicated script such as this means not being able to
use mk-origtargz. I would find that a bit unfortunate, because I'd hate this
package to be a snowflake in the go-lang packaging team. Or do we already
have similar snowflakes?

what does the team think which approach is better?


-rt

On Fri, Mar 1, 2019 at 2:55 AM Simon McVittie  wrote:

>
> You could consider using a multiple-.orig-tarball package in 3.0
> (quilt) format? See for example yquake2 (a relatively simple
> example which bundles together https://github.com/yquake2/yquake2 and
> https://github.com/yquake2/ctf) or llvm-toolchain-7 (a more elaborate
> example with multiple subprojects).
>
> smcv
>
>

-- 
regards,
Reinhard

Re: Bug#923300: ITP: golang-github-openshift-imagebuilder -- Builds Dockerfile using the Docker client

[Reinhard Tartler]

That sounds really promising. I wonder how to implement it for this package.

The yquake2 package uses gbp-buildpackage, pristine-tar and mk-origtargz,
which I would love to continue using. Unlike yquake2, this package doesn't
combine two seperate git repositories, but both sources come from the same
upstream repository. Also, I would like the component to be placed in the
subdirectory vendor/github.com/docker/docker, but to it seems to me that
"components" may not include the "/" (or I missed how the "/" gets mangled).
In conclusion, this means that "components" may only be placed at the
top-level source directory.

I guess what I can (should?) do is adjust the debian/copyright
Files-Excluded field
to exclude all entries but vendor/github.com/docker/docker, and use declare
a 'vendor' component. Then I probably can use mk-origtargz to
create both the "orig.tar.gz" as well as the "orig-vendor.tar.gz".

That would, however, lead to a *very* elaborate Files-Excluded field.

Does this make sense, or is there a simpler solution?

The llvm-toolchain-7 example does not use gbp-buildpackage or pristine-tar.
Instead
they apparently have a script that generates all tarballs:
https://sources.debian.org/src/llvm-toolchain-7/1:7.0.1-8/debian/orig-tar.sh/
I guess having a dedicated script such as this means not being able to
use mk-origtargz. I would find that a bit unfortunate, because I'd hate this
package to be a snowflake in the go-lang packaging team. Or do we already
have similar snowflakes?

what does the team think which approach is better?


-rt

On Fri, Mar 1, 2019 at 2:55 AM Simon McVittie  wrote:

>
> You could consider using a multiple-.orig-tarball package in 3.0
> (quilt) format? See for example yquake2 (a relatively simple
> example which bundles together https://github.com/yquake2/yquake2 and
> https://github.com/yquake2/ctf) or llvm-toolchain-7 (a more elaborate
> example with multiple subprojects).
>
> smcv
>
>

-- 
regards,
Reinhard

Re: Bug#923300: ITP: golang-github-openshift-imagebuilder -- Builds Dockerfile using the Docker client

[Reinhard Tartler]

That sounds really promising. I wonder how to implement it for this package.

The yquake2 package uses gbp-buildpackage, pristine-tar and mk-origtargz,
which I would love to continue using. Unlike yquake2, this package doesn't
combine two seperate git repositories, but both sources come from the same
upstream repository. Also, I would like the component to be placed in the
subdirectory vendor/github.com/docker/docker, but to it seems to me that
"components" may not include the "/" (or I missed how the "/" gets mangled).
In conclusion, this means that "components" may only be placed at the
top-level source directory.

I guess what I can (should?) do is adjust the debian/copyright
Files-Excluded field
to exclude all entries but vendor/github.com/docker/docker, and use declare
a 'vendor' component. Then I probably can use mk-origtargz to
create both the "orig.tar.gz" as well as the "orig-vendor.tar.gz".

That would, however, lead to a *very* elaborate Files-Excluded field.

Does this make sense, or is there a simpler solution?

The llvm-toolchain-7 example does not use gbp-buildpackage or pristine-tar.
Instead
they apparently have a script that generates all tarballs:
https://sources.debian.org/src/llvm-toolchain-7/1:7.0.1-8/debian/orig-tar.sh/
I guess having a dedicated script such as this means not being able to
use mk-origtargz. I would find that a bit unfortunate, because I'd hate this
package to be a snowflake in the go-lang packaging team. Or do we already
have similar snowflakes?

what does the team think which approach is better?


-rt

On Fri, Mar 1, 2019 at 2:55 AM Simon McVittie  wrote:

>
> You could consider using a multiple-.orig-tarball package in 3.0
> (quilt) format? See for example yquake2 (a relatively simple
> example which bundles together https://github.com/yquake2/yquake2 and
> https://github.com/yquake2/ctf) or llvm-toolchain-7 (a more elaborate
> example with multiple subprojects).
>
> smcv
>
>

-- 
regards,
Reinhard

Bug#923300: ITP: golang-github-openshift-imagebuilder -- Builds Dockerfile using the Docker client

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-openshift-imagebuilder
  Version : 1.0+git20190212.3682349-1
  Upstream Author : OpenShift
* URL : https://github.com/openshift/imagebuilder
* License : Apache-2.0
  Programming Lang: Go
  Description : Builds Dockerfile using the Docker client

 This library supports using the Dockerfile syntax to build OCI & Docker
 compatible images, without invoking a container build command such
 as buildah bud or docker build. It is intended to give clients more
 control over how they build container images, including: • Instead
 of building one layer per line, run all instructions in the same
 container• Set HostConfig settings like network and memory controls
 that are not available when running container builds• Mount external
 files into the build that are not persisted as part of the final image
 (i.e. "secrets")• If there are no RUN commands in the Dockerfile, the
 container is created and committed, but never started.  The final image
 should be 99.9% compatible with regular container builds, but bugs are
 always possible.


This is a build dependency of the buildah tool.

A particular challenge with this package is that it vendors in an old
version of the "docker" library. This has been reported by one of the
maintainers of the buildah project as 
https://github.com/openshift/imagebuilder/issues/116

Upstream doesn't appear to be willing to upgrade to a new version (quote from
the bug above "[...] I really don't want to [...]". Looking at how this package
is using the vendored library, it seems openshift/imagebuilder is using a
rather specific subset of the docker code, some of which possibly shouldn't
have been exposed in the first place. Therefore, I'm inclined to follow
upstream and vendor this library. My question here is what is the best way of
implementing this. I could update the Files-Excluded field in debian/copyright
to exclude all entries but openshift/imagebuilder, and use mk-origtargz to
strip the tarball. That would, however, lead to a *very* elaborate
Files-Excluded field. I wonder whether it wouldn't be actually be more
appropriate to create a tarbal with the vendored library and ship it in the
debian/ subdirectory. Has anyone else encountered this issue and/or could point
to other packages solving the same or a similar issue?

Cheers,
-rt

Bug#923300: ITP: golang-github-openshift-imagebuilder -- Builds Dockerfile using the Docker client

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-openshift-imagebuilder
  Version : 1.0+git20190212.3682349-1
  Upstream Author : OpenShift
* URL : https://github.com/openshift/imagebuilder
* License : Apache-2.0
  Programming Lang: Go
  Description : Builds Dockerfile using the Docker client

 This library supports using the Dockerfile syntax to build OCI & Docker
 compatible images, without invoking a container build command such
 as buildah bud or docker build. It is intended to give clients more
 control over how they build container images, including: • Instead
 of building one layer per line, run all instructions in the same
 container• Set HostConfig settings like network and memory controls
 that are not available when running container builds• Mount external
 files into the build that are not persisted as part of the final image
 (i.e. "secrets")• If there are no RUN commands in the Dockerfile, the
 container is created and committed, but never started.  The final image
 should be 99.9% compatible with regular container builds, but bugs are
 always possible.


This is a build dependency of the buildah tool.

A particular challenge with this package is that it vendors in an old
version of the "docker" library. This has been reported by one of the
maintainers of the buildah project as 
https://github.com/openshift/imagebuilder/issues/116

Upstream doesn't appear to be willing to upgrade to a new version (quote from
the bug above "[...] I really don't want to [...]". Looking at how this package
is using the vendored library, it seems openshift/imagebuilder is using a
rather specific subset of the docker code, some of which possibly shouldn't
have been exposed in the first place. Therefore, I'm inclined to follow
upstream and vendor this library. My question here is what is the best way of
implementing this. I could update the Files-Excluded field in debian/copyright
to exclude all entries but openshift/imagebuilder, and use mk-origtargz to
strip the tarball. That would, however, lead to a *very* elaborate
Files-Excluded field. I wonder whether it wouldn't be actually be more
appropriate to create a tarbal with the vendored library and ship it in the
debian/ subdirectory. Has anyone else encountered this issue and/or could point
to other packages solving the same or a similar issue?

Cheers,
-rt

Bug#923300: ITP: golang-github-openshift-imagebuilder -- Builds Dockerfile using the Docker client

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-openshift-imagebuilder
  Version : 1.0+git20190212.3682349-1
  Upstream Author : OpenShift
* URL : https://github.com/openshift/imagebuilder
* License : Apache-2.0
  Programming Lang: Go
  Description : Builds Dockerfile using the Docker client

 This library supports using the Dockerfile syntax to build OCI & Docker
 compatible images, without invoking a container build command such
 as buildah bud or docker build. It is intended to give clients more
 control over how they build container images, including: • Instead
 of building one layer per line, run all instructions in the same
 container• Set HostConfig settings like network and memory controls
 that are not available when running container builds• Mount external
 files into the build that are not persisted as part of the final image
 (i.e. "secrets")• If there are no RUN commands in the Dockerfile, the
 container is created and committed, but never started.  The final image
 should be 99.9% compatible with regular container builds, but bugs are
 always possible.


This is a build dependency of the buildah tool.

A particular challenge with this package is that it vendors in an old
version of the "docker" library. This has been reported by one of the
maintainers of the buildah project as 
https://github.com/openshift/imagebuilder/issues/116

Upstream doesn't appear to be willing to upgrade to a new version (quote from
the bug above "[...] I really don't want to [...]". Looking at how this package
is using the vendored library, it seems openshift/imagebuilder is using a
rather specific subset of the docker code, some of which possibly shouldn't
have been exposed in the first place. Therefore, I'm inclined to follow
upstream and vendor this library. My question here is what is the best way of
implementing this. I could update the Files-Excluded field in debian/copyright
to exclude all entries but openshift/imagebuilder, and use mk-origtargz to
strip the tarball. That would, however, lead to a *very* elaborate
Files-Excluded field. I wonder whether it wouldn't be actually be more
appropriate to create a tarbal with the vendored library and ship it in the
debian/ subdirectory. Has anyone else encountered this issue and/or could point
to other packages solving the same or a similar issue?

Cheers,
-rt

Bug#880199: ITP: skopeo -- Utility performing various operations on container images and image repositories

[Reinhard Tartler]

Control: owner -1 !

I've started to work on packaging skopeo, you can find the packaging at
https://salsa.debian.org/go-team/packages/skopeo

Note that it depends on some additional packages currently found in the NEW
queue, but I've been able to build and install the package in a chroot.

Testing and comments on the packaging would be very appreciated.

One thing that bugs me is that I had to disable the test suite. Help on
getting that part to work would be most helpful!

Best,
-rt


-- 
regards,
Reinhard

Bug#880199: ITP: skopeo -- Utility performing various operations on container images and image repositories

[Reinhard Tartler]

Control: owner -1 !

I've started to work on packaging skopeo, you can find the packaging at
https://salsa.debian.org/go-team/packages/skopeo

Note that it depends on some additional packages currently found in the NEW
queue, but I've been able to build and install the package in a chroot.

Testing and comments on the packaging would be very appreciated.

One thing that bugs me is that I had to disable the test suite. Help on
getting that part to work would be most helpful!

Best,
-rt


-- 
regards,
Reinhard

Bug#922842: ITP: golang-github-containers-image -- Work with containers' images

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-containers-image
  Version : 1.2+git20181221.f0cbc16-1
  Upstream Author : Antonio Murdaca 
Brandon Philips 
Miloslav Trmac 
Dan Walsh 
Nalin Dahyabhai 
* URL : https://github.com/containers/image
* License : Apache-2.0
  Programming Lang: Go
  Description : Work with containers' images

 This library is aimed at working in various way with containers' images
 and container image registries. Itallows application to pull and push
 images from container image registries, like the upstream docker
 registry, and also implements "simple image signing".

Please see
https://www.redhat.com/en/blog/working-container-storage-library-and-tools-red-hat-enterprise-linux
for some more background on this library. It is a dependency for
skopeo, podman and buildah.

This package is going to be maintained within the go team on salsa:
https://salsa.debian.org/go-team/packages/golang-github-containers-image

Bug#922842: ITP: golang-github-containers-image -- Work with containers' images

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-containers-image
  Version : 1.2+git20181221.f0cbc16-1
  Upstream Author : Antonio Murdaca 
Brandon Philips 
Miloslav Trmac 
Dan Walsh 
Nalin Dahyabhai 
* URL : https://github.com/containers/image
* License : Apache-2.0
  Programming Lang: Go
  Description : Work with containers' images

 This library is aimed at working in various way with containers' images
 and container image registries. Itallows application to pull and push
 images from container image registries, like the upstream docker
 registry, and also implements "simple image signing".

Please see
https://www.redhat.com/en/blog/working-container-storage-library-and-tools-red-hat-enterprise-linux
for some more background on this library. It is a dependency for
skopeo, podman and buildah.

This package is going to be maintained within the go team on salsa:
https://salsa.debian.org/go-team/packages/golang-github-containers-image

Bug#922842: ITP: golang-github-containers-image -- Work with containers' images

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-containers-image
  Version : 1.2+git20181221.f0cbc16-1
  Upstream Author : Antonio Murdaca 
Brandon Philips 
Miloslav Trmac 
Dan Walsh 
Nalin Dahyabhai 
* URL : https://github.com/containers/image
* License : Apache-2.0
  Programming Lang: Go
  Description : Work with containers' images

 This library is aimed at working in various way with containers' images
 and container image registries. Itallows application to pull and push
 images from container image registries, like the upstream docker
 registry, and also implements "simple image signing".

Please see
https://www.redhat.com/en/blog/working-container-storage-library-and-tools-red-hat-enterprise-linux
for some more background on this library. It is a dependency for
skopeo, podman and buildah.

This package is going to be maintained within the go team on salsa:
https://salsa.debian.org/go-team/packages/golang-github-containers-image

Bug#922842: ITP: golang-github-containers-image -- Work with containers' images

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-containers-image
  Version : 1.2+git20181221.f0cbc16-1
  Upstream Author : Antonio Murdaca 
Brandon Philips 
Miloslav Trmac 
Dan Walsh 
Nalin Dahyabhai 
* URL : https://github.com/containers/image
* License : Apache-2.0
  Programming Lang: Go
  Description : Work with containers' images

 This library is aimed at working in various way with containers' images
 and container image registries. Itallows application to pull and push
 images from container image registries, like the upstream docker
 registry, and also implements "simple image signing".

Please see
https://www.redhat.com/en/blog/working-container-storage-library-and-tools-red-hat-enterprise-linux
for some more background on this library. It is a dependency for
skopeo, podman and buildah.

This package is going to be maintained within the go team on salsa:
https://salsa.debian.org/go-team/packages/golang-github-containers-image

dh_golang fails because a package got completely disabled with tags

[Reinhard Tartler]

Hi Michael,

I'm not sure if this constitutes a bug in dh_golang, so I'm writing here
first. I'm working on
https://salsa.debian.org/go-team/packages/golang-github-containers-image
which needs buildtags to avoid a dependency on ostree.

I'm in contact with upstream and we agreed that this dependency in not
worth the trouble keeping we agreed that for Debian, the best way to
proceed would be to use the buildtag containers_image_ostree_stub which
disables the package "github.com/containers/image/ostree".

As your recommendations in the other email thread, I've added the -tag
option to the dh_auto_build invocation. That appears to work fine.

However, the package build fails at the invocation of dh_golang. If I
understand the utility correctly, it invokes "go list" two times: The first
time to identify the golang packages that needs to be installed into the
Debian package, and a second time to identify what files are involved?
(Sorry, Perl is not my forte, and I think some commentary in the source
code on the thinking behind the '$tmpl' and '$gofiletmpl' variables that
are being passed to "go list" would be very valuable).

If I understand the control flow correctly, it is the 2nd invocation that
crashes with this error message:


   dh_golang -O--buildsystem=golang
can't load package: obj-x86_64-linux-gnu/src/
github.com/containers/image/ostree/ostree_src.go:21:2: cannot find package "
github.com/ostreedev/ostree-go/pkg/glibobject" in any of:
/usr/lib/go-1.11/src/github.com/ostreedev/ostree-go/pkg/glibobject
(from $GOROOT)
/<>/obj-x86_64-linux-gnu/src/
github.com/ostreedev/ostree-go/pkg/glibobject (from $GOPATH)
can't load package: obj-x86_64-linux-gnu/src/
github.com/containers/image/ostree/ostree_dest.go:29:2: cannot find package
"github.com/ostreedev/ostree-go/pkg/otbuiltin" in any of:
/usr/lib/go-1.11/src/github.com/ostreedev/ostree-go/pkg/otbuiltin
(from $GOROOT)
/<>/obj-x86_64-linux-gnu/src/
github.com/ostreedev/ostree-go/pkg/otbuiltin (from $GOPATH)
dh_golang: go list -f '\
{{ .Dir }}/{{ index (or .GoFiles .CgoFiles .TestGoFiles .XTestGoFiles
.IgnoredGoFiles) 0 }}' returned exit code 1
make: *** [debian/rules:8: binary] Error 1
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned
exit status 2


I believe fixing this might require changes in dh_golang, but I'd really
appreciate your opinion on this. Maybe there is a simple(r) solution that I
may be overlooking?

Thanks!

-- 
regards,
Reinhard

Re: Setting build tags in dh-golang

[Reinhard Tartler]

Awesome, thanks!

One thing that I noticed is that I apparently can't add the tags to the '%'
rule, I do need to override 'dh_auto_build'. That's strange..

TBH, since much of the debhelper's behavior is currently controlled via
environment variables, I somehow had expected to set them that way as well.
This way, I wouldn't have to add overrides.

Michael, have you considered this idea before?

Best,
-rt

On Fri, Feb 15, 2019 at 7:15 AM Michael Stapelberg 
wrote:

> You can find a few examples using
> https://codesearch.debian.net/search?q=path%3Adebian%2Frules+tag+path%3Agolang,
> e.g.
> https://sources.debian.org/src/golang-golang-x-sys/0.0~git20181228.9a3f9b0-1/debian/rules/?hl=40#L40
>
> In general, I would encourage you to nudge upstream to make the default
> behavior sensitive and only require build tags for unusual setups.
>
> Also, please feel free to send documentation improvement pull requests :)
>
> On Fri, Feb 15, 2019 at 1:12 PM Reinhard Tartler 
> wrote:
>
>> Hi,
>>
>> I may be missing something obvious, but I'm looking for a way to set
>> build tags in debian/rules.
>>
>> While working on the github.com/containers/image library, upstream has
>> advised me to avoid some dependencies by setting build tags. After reading
>> the Debian::Debhelper::Buildsystem::golang perldoc it is not clear to me
>> how to achieve this. (BTW, I would have expected lots of the information
>> found in that perldoc to in the manpage dh_golang(1p).
>>
>> Has this been done in other packages before where I could take
>> inspiration from?
>>
>> Thanks!
>>
>> --
>> regards,
>> Reinhard
>>
>
>
> --
> Best regards,
> Michael
>


-- 
regards,
Reinhard

Setting build tags in dh-golang

[Reinhard Tartler]

Hi,

I may be missing something obvious, but I'm looking for a way to set build
tags in debian/rules.

While working on the github.com/containers/image library, upstream has
advised me to avoid some dependencies by setting build tags. After reading
the Debian::Debhelper::Buildsystem::golang perldoc it is not clear to me
how to achieve this. (BTW, I would have expected lots of the information
found in that perldoc to in the manpage dh_golang(1p).

Has this been done in other packages before where I could take inspiration
from?

Thanks!

-- 
regards,
Reinhard

Bug#782093: For more details on chapter file syntax...broken link

[Reinhard Tartler]

Control: tag -1 upstream

Hi Mathieu,

Sorry for the late reply.

This is an upstream issue and needs to be dealt as such. Can you please
visit https://github.com/gpac/gpac/issues/new and report back the issue
number you got? I'd be happy to add the necessary linking so that we are
notified when this gets resolved upstream.

Thanks for your understanding.


On Tue, Apr 7, 2015 at 3:57 PM Mathieu Malaterre  wrote:

> Package: gpac
> Version: 0.5.0+svn5324~dfsg1-1+b3
> Severity: minor
>
> The man page point to broken link:
>
> [...]
>-chap chap_file
>   adds chapter information contained in chap_file to
> movie. For more details on chapter file syntax, cf
> http://gpac.sourceforge.net/auth_mp4box.php.
> [...]
>
> While:
>
> $ HEAD http://gpac.sourceforge.net/auth_mp4box.php
> 404 Not Found
> Connection: close
> Date: Tue, 07 Apr 2015 19:54:39 GMT
> Via: 1.1 varnish
> Age: 0
> Server: Apache/2.2.15 (CentOS)
> Vary: Host
> Content-Length: 1677
> Content-Type: text/html
> Client-Date: Tue, 07 Apr 2015 19:54:40 GMT
> Client-Peer: 216.34.181.96:80
> Client-Response-Num: 1
> X-Varnish: 838453151
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
>
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
>


-- 
regards,
Reinhard

Bug#782093: For more details on chapter file syntax...broken link

[Reinhard Tartler]

Control: tag -1 upstream

Hi Mathieu,

Sorry for the late reply.

This is an upstream issue and needs to be dealt as such. Can you please
visit https://github.com/gpac/gpac/issues/new and report back the issue
number you got? I'd be happy to add the necessary linking so that we are
notified when this gets resolved upstream.

Thanks for your understanding.


On Tue, Apr 7, 2015 at 3:57 PM Mathieu Malaterre  wrote:

> Package: gpac
> Version: 0.5.0+svn5324~dfsg1-1+b3
> Severity: minor
>
> The man page point to broken link:
>
> [...]
>-chap chap_file
>   adds chapter information contained in chap_file to
> movie. For more details on chapter file syntax, cf
> http://gpac.sourceforge.net/auth_mp4box.php.
> [...]
>
> While:
>
> $ HEAD http://gpac.sourceforge.net/auth_mp4box.php
> 404 Not Found
> Connection: close
> Date: Tue, 07 Apr 2015 19:54:39 GMT
> Via: 1.1 varnish
> Age: 0
> Server: Apache/2.2.15 (CentOS)
> Vary: Host
> Content-Length: 1677
> Content-Type: text/html
> Client-Date: Tue, 07 Apr 2015 19:54:40 GMT
> Client-Peer: 216.34.181.96:80
> Client-Response-Num: 1
> X-Varnish: 838453151
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
>
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
>


-- 
regards,
Reinhard

Bug#786733: gpac: aac2m4a, some m4a are 1 second long and <1Kb big

[Reinhard Tartler]

Control: tag -1 upstream

Hi Tiberio,

Sorry for the late reply.

This is an upstream issue and needs to be dealt as such. Can you please
visit https://github.com/gpac/gpac/issues/new and report back the issue
number you got? I'd be happy to add the necessary linking so that we are
notified when this gets resolved upstream.

Thanks for your understanding.

On Sun, May 24, 2015 at 8:48 PM Tiberio Galletti  wrote:

> Package: gpac
> Version: 0.5.0+svn5324~dfsg1-1+b3
> Severity: important
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate
> ***
>
> Converting aac files (built by streamripper) to m4a ones.
>
> MP4Box -add foo.acc bar.m4a -new
>
> many files were incapsulated ok, many m4a files are smaller than 1Kb and
> mediainfo says they are long 1 second only hand have a bitrate higher than
> 5000bps
>
> previous release (oldstable repository) convert all aac files to m4a. No
> files smaller than 1kb, no songs shorter than 1 second. I tested same songs!
>
>
> -- System Information:
> Debian Release: 8.0
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'proposed-updates'), (500,
> 'oldstable'), (90, 'testing'), (30, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages gpac depends on:
> ii  gpac-modules-base0.5.0+svn5324~dfsg1-1+b3
> ii  libavcodec-extra-56  6:11.3-1
> ii  libavdevice556:11.3-1
> ii  libavformat566:11.3-1
> ii  libavresample2   6:11.3-1
> ii  libavutil54  6:11.3-1
> ii  libc62.19-18
> ii  libgpac3 0.5.0+svn5324~dfsg1-1+b3
> ii  libswscale3  6:11.3-1
>
> gpac recommends no packages.
>
> gpac suggests no packages.
>
> -- no debconf information
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
>
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
>


-- 
regards,
Reinhard