Bug#898689: ITP: golang-github-ostreedev-ostree-go -- Golang bindings for httt://github.com/ostreedev/ostree
On Wed, Jan 9, 2019 at 9:58 AM Alexandre Viau wrote: > On 2019-01-09 6:54 a.m., Reinhard Tartler wrote: > > Hi Juan, > > > > are you still working on this ITP? I was looking at skopeo as well, > > and stumpled upon this ITP. I noticed that you created a repository on > > salsa: > > > > > https://salsa.debian.org/go-team/packages/golang-github-ostreedev-ostree-go > > > > This package never got uploaded. > > > > However, I also noticed that there is another packaging repo in salsa, > > which contains a similar package that did get uploaded: > > > > > https://salsa.debian.org/go-team/packages/golang-github-sjoerdsimons-ostree-go > > https://tracker.debian.org/pkg/golang-github-sjoerdsimons-ostree-go > > > > I wonder what the relationship between these two are. It seems that the > > sjoerdsimons > > version does declare it satisfies the import of the > > github:ostreedev/ostree-go repo, > > which makes me believe it is a fork. > > Looking at the upstream website will show you that yes it is a fork. > (forked from ostreedev/ostree). > > I'm slowly making progress towards to goal of packaging skopeo, and have arrived at packaging the containers/image package. It also requires compiling against the ostree-dev library (like containers/storage), but this time it fails to build: # github.com/sjoerdsimons/ostree-go/pkg/otbuiltin In file included from /usr/include/glib-2.0/glib/glist.h:32, from /usr/include/glib-2.0/glib/ghash.h:33, from /usr/include/glib-2.0/glib.h:50, from src/ github.com/sjoerdsimons/ostree-go/pkg/otbuiltin/builtin.go:16: src/github.com/sjoerdsimons/ostree-go/pkg/otbuiltin/builtin.go.h: In function '_g_clear_object': /usr/include/glib-2.0/glib/gmem.h:121:18: warning: passing argument 1 of 'g_object_unref' discards 'volatile' qualifier from pointer target type [-Wdiscarded-qualifiers] (destroy) (_ptr); \ ^~~~ /usr/include/glib-2.0/gobject/gobject.h:672:36: note: in expansion of macro 'g_clear_pointer' #define g_clear_object(object_ptr) g_clear_pointer ((object_ptr), g_object_unref) ^~~ src/github.com/sjoerdsimons/ostree-go/pkg/otbuiltin/builtin.go.h:51:3: note: in expansion of macro 'g_clear_object' g_clear_object(object_ptr); ^~ I noticed that a very similar error is mentioned in a commit message of the upstream fork (ostreedev/ostree-go): https://github.com/ostreedev/ostree-go/commit/7af23efc78cbcbf462ae58e30fc4b94e99f09436#diff-898ad6510d1fe82a218a36340e3b56ec I strongly suspect that compiling against ostreedev/ostree-go would fix this issue. Given that https://github.com/sjoerdsimons/ostree-go/blob/master/README.md clearly states: Temporary repository for patches not yet merged in upstream ostree-go. > Please don't use this one but use https://github.com/ostreedev/ostree-go > instead I wonder why we are are using this fork in the first place. Hector, Andrej, Alex, can you please chime in? Can we avoid having two copies of this library in the archive or is that the best way to proceed for now? Best, -rt
Bug#898689: ITP: golang-github-ostreedev-ostree-go -- Golang bindings for httt://github.com/ostreedev/ostree
On Wed, Jan 9, 2019 at 9:58 AM Alexandre Viau wrote: > On 2019-01-09 6:54 a.m., Reinhard Tartler wrote: > > Hi Juan, > > > > are you still working on this ITP? I was looking at skopeo as well, > > and stumpled upon this ITP. I noticed that you created a repository on > > salsa: > > > > > https://salsa.debian.org/go-team/packages/golang-github-ostreedev-ostree-go > > > > This package never got uploaded. > > > > However, I also noticed that there is another packaging repo in salsa, > > which contains a similar package that did get uploaded: > > > > > https://salsa.debian.org/go-team/packages/golang-github-sjoerdsimons-ostree-go > > https://tracker.debian.org/pkg/golang-github-sjoerdsimons-ostree-go > > > > I wonder what the relationship between these two are. It seems that the > > sjoerdsimons > > version does declare it satisfies the import of the > > github:ostreedev/ostree-go repo, > > which makes me believe it is a fork. > > Looking at the upstream website will show you that yes it is a fork. > (forked from ostreedev/ostree). > > I'm slowly making progress towards to goal of packaging skopeo, and have arrived at packaging the containers/image package. It also requires compiling against the ostree-dev library (like containers/storage), but this time it fails to build: # github.com/sjoerdsimons/ostree-go/pkg/otbuiltin In file included from /usr/include/glib-2.0/glib/glist.h:32, from /usr/include/glib-2.0/glib/ghash.h:33, from /usr/include/glib-2.0/glib.h:50, from src/ github.com/sjoerdsimons/ostree-go/pkg/otbuiltin/builtin.go:16: src/github.com/sjoerdsimons/ostree-go/pkg/otbuiltin/builtin.go.h: In function '_g_clear_object': /usr/include/glib-2.0/glib/gmem.h:121:18: warning: passing argument 1 of 'g_object_unref' discards 'volatile' qualifier from pointer target type [-Wdiscarded-qualifiers] (destroy) (_ptr); \ ^~~~ /usr/include/glib-2.0/gobject/gobject.h:672:36: note: in expansion of macro 'g_clear_pointer' #define g_clear_object(object_ptr) g_clear_pointer ((object_ptr), g_object_unref) ^~~ src/github.com/sjoerdsimons/ostree-go/pkg/otbuiltin/builtin.go.h:51:3: note: in expansion of macro 'g_clear_object' g_clear_object(object_ptr); ^~ I noticed that a very similar error is mentioned in a commit message of the upstream fork (ostreedev/ostree-go): https://github.com/ostreedev/ostree-go/commit/7af23efc78cbcbf462ae58e30fc4b94e99f09436#diff-898ad6510d1fe82a218a36340e3b56ec I strongly suspect that compiling against ostreedev/ostree-go would fix this issue. Given that https://github.com/sjoerdsimons/ostree-go/blob/master/README.md clearly states: Temporary repository for patches not yet merged in upstream ostree-go. > Please don't use this one but use https://github.com/ostreedev/ostree-go > instead I wonder why we are are using this fork in the first place. Hector, Andrej, Alex, can you please chime in? Can we avoid having two copies of this library in the archive or is that the best way to proceed for now? Best, -rt
Bug#922124: ITP: golang-github-ulikunitz-xz -- Pure golang package for reading and writing xz-compressed files
Thanks for the review, I've just uploaded it to unstable. -rt On 2/12/19 8:13 AM, eamanu15 wrote: > Oh thanks! I can see now > > Take care that the d/changelog entry is on UNRELEASED; > > Regards > > El mar., 12 de feb. de 2019 a la(s) 09:57, Reinhard Tartler > (siret...@tauware.de <mailto:siret...@tauware.de>) escribió: > > > > On 2/12/19 7:17 AM, eamanu15 wrote: > > Hi, > > > > The salsa repo is empty. > > > > Something is wrong? > > The train station arrived sooner than I could push to salsa. I've just > rectified this, the repository is now populated. > > https://salsa.debian.org/go-team/packages/golang-github-ulikunitz-xz > > Thanks for your interest! > -rt > > > > -- > Arias Emmanuel > http://eamanu.com > Github/Gitlab; @eamanu > Debian: @eamanu-guest
Bug#922124: ITP: golang-github-ulikunitz-xz -- Pure golang package for reading and writing xz-compressed files
Thanks for the review, I've just uploaded it to unstable. -rt On 2/12/19 8:13 AM, eamanu15 wrote: > Oh thanks! I can see now > > Take care that the d/changelog entry is on UNRELEASED; > > Regards > > El mar., 12 de feb. de 2019 a la(s) 09:57, Reinhard Tartler > (siret...@tauware.de <mailto:siret...@tauware.de>) escribió: > > > > On 2/12/19 7:17 AM, eamanu15 wrote: > > Hi, > > > > The salsa repo is empty. > > > > Something is wrong? > > The train station arrived sooner than I could push to salsa. I've just > rectified this, the repository is now populated. > > https://salsa.debian.org/go-team/packages/golang-github-ulikunitz-xz > > Thanks for your interest! > -rt > > > > -- > Arias Emmanuel > http://eamanu.com > Github/Gitlab; @eamanu > Debian: @eamanu-guest
Bug#922124: ITP: golang-github-ulikunitz-xz -- Pure golang package for reading and writing xz-compressed files
On 2/12/19 7:17 AM, eamanu15 wrote: > Hi, > > The salsa repo is empty. > > Something is wrong? The train station arrived sooner than I could push to salsa. I've just rectified this, the repository is now populated. https://salsa.debian.org/go-team/packages/golang-github-ulikunitz-xz Thanks for your interest! -rt
Bug#922124: ITP: golang-github-ulikunitz-xz -- Pure golang package for reading and writing xz-compressed files
On 2/12/19 7:17 AM, eamanu15 wrote: > Hi, > > The salsa repo is empty. > > Something is wrong? The train station arrived sooner than I could push to salsa. I've just rectified this, the repository is now populated. https://salsa.debian.org/go-team/packages/golang-github-ulikunitz-xz Thanks for your interest! -rt
Bug#922124: ITP: golang-github-ulikunitz-xz -- Pure golang package for reading and writing xz-compressed files
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: golang-github-ulikunitz-xz Version : 0.5.5-1 Upstream Author : Ulrich Kunitz * URL : https://github.com/ulikunitz/xz * License : 3-clause BSD Programming Lang: Go Description : Pure golang package for reading and writing xz-compressed files Package xz This Go language package supports the reading and writing of xz compressed streams. It includes also a gxz command for compressing and decompressing data. The package is completely written in Go and doesn't have any dependency on any C code. Rationale: This is a build dependency of github.com/containers/storage. I intend to maintain this package under the pkg-go umbrella at https://salsa.debian.org/go-team/packages/golang-github-ulikunitz-xz
Bug#922124: ITP: golang-github-ulikunitz-xz -- Pure golang package for reading and writing xz-compressed files
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: golang-github-ulikunitz-xz Version : 0.5.5-1 Upstream Author : Ulrich Kunitz * URL : https://github.com/ulikunitz/xz * License : 3-clause BSD Programming Lang: Go Description : Pure golang package for reading and writing xz-compressed files Package xz This Go language package supports the reading and writing of xz compressed streams. It includes also a gxz command for compressing and decompressing data. The package is completely written in Go and doesn't have any dependency on any C code. Rationale: This is a build dependency of github.com/containers/storage. I intend to maintain this package under the pkg-go umbrella at https://salsa.debian.org/go-team/packages/golang-github-ulikunitz-xz
Bug#922124: ITP: golang-github-ulikunitz-xz -- Pure golang package for reading and writing xz-compressed files
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: golang-github-ulikunitz-xz Version : 0.5.5-1 Upstream Author : Ulrich Kunitz * URL : https://github.com/ulikunitz/xz * License : 3-clause BSD Programming Lang: Go Description : Pure golang package for reading and writing xz-compressed files Package xz This Go language package supports the reading and writing of xz compressed streams. It includes also a gxz command for compressing and decompressing data. The package is completely written in Go and doesn't have any dependency on any C code. Rationale: This is a build dependency of github.com/containers/storage. I intend to maintain this package under the pkg-go umbrella at https://salsa.debian.org/go-team/packages/golang-github-ulikunitz-xz
Bug#922124: ITP: golang-github-ulikunitz-xz -- Pure golang package for reading and writing xz-compressed files
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: golang-github-ulikunitz-xz Version : 0.5.5-1 Upstream Author : Ulrich Kunitz * URL : https://github.com/ulikunitz/xz * License : 3-clause BSD Programming Lang: Go Description : Pure golang package for reading and writing xz-compressed files Package xz This Go language package supports the reading and writing of xz compressed streams. It includes also a gxz command for compressing and decompressing data. The package is completely written in Go and doesn't have any dependency on any C code. Rationale: This is a build dependency of github.com/containers/storage. I intend to maintain this package under the pkg-go umbrella at https://salsa.debian.org/go-team/packages/golang-github-ulikunitz-xz
Bug#922089: ITP: golang-github-mtrmac-gpgme -- Go wrapper for the GPGME library
I was running into issues with getting the testsuite pass during a package build. The testsuite does pass when I 'go get' the library and call it manually with 'go test'. I straced the failing execution and came to the conclusion that something funny must be going on with interacting with gpg-agent. During this investigation, I've noticed that this repository is a fork of github.com/proglottis/gpgme, which we already have in debian. I'll therefore suspend my work on this package for now and will try to patch github.com/containers/storage to compile against the original version instead. If that doesn't work out, I may need to get back to this ITP... Best, -rt
Bug#922089: ITP: golang-github-mtrmac-gpgme -- Go wrapper for the GPGME library
I was running into issues with getting the testsuite pass during a package build. The testsuite does pass when I 'go get' the library and call it manually with 'go test'. I straced the failing execution and came to the conclusion that something funny must be going on with interacting with gpg-agent. During this investigation, I've noticed that this repository is a fork of github.com/proglottis/gpgme, which we already have in debian. I'll therefore suspend my work on this package for now and will try to patch github.com/containers/storage to compile against the original version instead. If that doesn't work out, I may need to get back to this ITP... Best, -rt
Re: Bug#922089: ITP: golang-github-mtrmac-gpgme -- Go wrapper for the GPGME library
I was running into issues with getting the testsuite pass during a package build. The testsuite does pass when I 'go get' the library and call it manually with 'go test'. I straced the failing execution and came to the conclusion that something funny must be going on with interacting with gpg-agent. During this investigation, I've noticed that this repository is a fork of github.com/proglottis/gpgme, which we already have in debian. I'll therefore suspend my work on this package for now and will try to patch github.com/containers/storage to compile against the original version instead. If that doesn't work out, I may need to get back to this ITP... Best, -rt
Bug#922089: ITP: golang-github-mtrmac-gpgme -- Go wrapper for the GPGME library
The plan is to maintain this package under to go-team umbrella. The packaging is at https://salsa.debian.org/go-team/packages/golang-github-mtrmac-gpgme. Comments / feedback welcome! -rt
Bug#922089: ITP: golang-github-mtrmac-gpgme -- Go wrapper for the GPGME library
The plan is to maintain this package under to go-team umbrella. The packaging is at https://salsa.debian.org/go-team/packages/golang-github-mtrmac-gpgme. Comments / feedback welcome! -rt
Re: Bug#922089: ITP: golang-github-mtrmac-gpgme -- Go wrapper for the GPGME library
The plan is to maintain this package under to go-team umbrella. The packaging is at https://salsa.debian.org/go-team/packages/golang-github-mtrmac-gpgme. Comments / feedback welcome! -rt
Bug#922089: ITP: golang-github-mtrmac-gpgme -- Go wrapper for the GPGME library
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: golang-github-mtrmac-gpgme Version : 0.0~git20170102.b243242-1 Upstream Author : Miloslav Trmač * URL : https://github.com/mtrmac/gpgme * License : BSD-3-clause Programming Lang: Go Description : Go wrapper for the GPGME library GPGME (golang) Go wrapper for the GPGME library. . This library is intended for use with desktop applications. This is a build dependency of http://github.com/containers/storage
Bug#922089: ITP: golang-github-mtrmac-gpgme -- Go wrapper for the GPGME library
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: golang-github-mtrmac-gpgme Version : 0.0~git20170102.b243242-1 Upstream Author : Miloslav Trmač * URL : https://github.com/mtrmac/gpgme * License : BSD-3-clause Programming Lang: Go Description : Go wrapper for the GPGME library GPGME (golang) Go wrapper for the GPGME library. . This library is intended for use with desktop applications. This is a build dependency of http://github.com/containers/storage
Bug#922089: ITP: golang-github-mtrmac-gpgme -- Go wrapper for the GPGME library
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: golang-github-mtrmac-gpgme Version : 0.0~git20170102.b243242-1 Upstream Author : Miloslav Trmač * URL : https://github.com/mtrmac/gpgme * License : BSD-3-clause Programming Lang: Go Description : Go wrapper for the GPGME library GPGME (golang) Go wrapper for the GPGME library. . This library is intended for use with desktop applications. This is a build dependency of http://github.com/containers/storage
Bug#922089: ITP: golang-github-mtrmac-gpgme -- Go wrapper for the GPGME library
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: golang-github-mtrmac-gpgme Version : 0.0~git20170102.b243242-1 Upstream Author : Miloslav Trmač * URL : https://github.com/mtrmac/gpgme * License : BSD-3-clause Programming Lang: Go Description : Go wrapper for the GPGME library GPGME (golang) Go wrapper for the GPGME library. . This library is intended for use with desktop applications. This is a build dependency of http://github.com/containers/storage
Bug#921949: ITP: golang-github-containers-storage --
I've pushed my current work to salsa. Feedback and suggestions would be much appreciated, as I'm still rather new to packaging go libraries. I intend to have this package team maintained. You can find the repository at https://salsa.debian.org/go-team/packages/golang-github-containers-storage
Bug#921949: ITP: golang-github-containers-storage --
I've pushed my current work to salsa. Feedback and suggestions would be much appreciated, as I'm still rather new to packaging go libraries. I intend to have this package team maintained. You can find the repository at https://salsa.debian.org/go-team/packages/golang-github-containers-storage
Re: Bug#921949: ITP: golang-github-containers-storage --
I've pushed my current work to salsa. Feedback and suggestions would be much appreciated, as I'm still rather new to packaging go libraries. I intend to have this package team maintained. You can find the repository at https://salsa.debian.org/go-team/packages/golang-github-containers-storage
Bug#921949: ITP: golang-github-containers-storage --
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: golang-github-containers-storage Version : 1.5-1 Upstream Author : * URL : https://github.com/containers/storage * License : Apache-2.0 Programming Lang: Go Description : Go library for handling how containers are stored on disk 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. Suggestions for improvements of the package description would be much appreciated. storage is a Go library which aims to provide methods for storing filesystem layers, container images, and containers. A containers-storage CLI wrapper is also included for manual and scripting use. . Operations which use VMs expect to launch them using 'vagrant', defaulting to using its 'libvirt' provider. The boxes used are also available for the 'virtualbox' provider, and can be selected by setting $VAGRANT_PROVIDER to 'virtualbox' before kicking off the build. . The library manages three types of items: layers, images, and containers. . A layer is a copy-on-write filesystem which is notionally stored as a set of changes relative to its parent layer, if it has one. A given layer can only have one parent, but any layer can be the parent of multiple layers. Layers which are parents of other layers should be treated as read-only. . An image is a reference to a particular layer (its top layer), along with other information which the library can manage for the convenience of its caller. This information typically includes configuration templates for running a binary contained within the image's layers, and may include cryptographic signatures. Multiple images can reference the same layer, as the differences between two images may not be in their layer contents. . A container is a read-write layer which is a child of an image's top layer, along with information which the library can manage for the convenience of its caller. This information typically includes configuration information for running the specific container. Multiple containers can be derived from a single image. . Layers, images, and containers are represented primarily by 32 character hexadecimal IDs, but items of each kind can also have one or more arbitrary names attached to them, which the library will automatically resolve to IDs when they are passed in to API calls which expect IDs. . The library can store what it calls metadata for each of these types of items. This is expected to be a small piece of data, since it is cached in memory and stored along with the library's own bookkeeping information. . Additionally, the library can store one or more of what it calls big data for images and containers. This is a named chunk of larger data, which is only in memory when it is being read from or being written to its own disk file.
Bug#921949: ITP: golang-github-containers-storage --
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: golang-github-containers-storage Version : 1.5-1 Upstream Author : * URL : https://github.com/containers/storage * License : Apache-2.0 Programming Lang: Go Description : Go library for handling how containers are stored on disk 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. Suggestions for improvements of the package description would be much appreciated. storage is a Go library which aims to provide methods for storing filesystem layers, container images, and containers. A containers-storage CLI wrapper is also included for manual and scripting use. . Operations which use VMs expect to launch them using 'vagrant', defaulting to using its 'libvirt' provider. The boxes used are also available for the 'virtualbox' provider, and can be selected by setting $VAGRANT_PROVIDER to 'virtualbox' before kicking off the build. . The library manages three types of items: layers, images, and containers. . A layer is a copy-on-write filesystem which is notionally stored as a set of changes relative to its parent layer, if it has one. A given layer can only have one parent, but any layer can be the parent of multiple layers. Layers which are parents of other layers should be treated as read-only. . An image is a reference to a particular layer (its top layer), along with other information which the library can manage for the convenience of its caller. This information typically includes configuration templates for running a binary contained within the image's layers, and may include cryptographic signatures. Multiple images can reference the same layer, as the differences between two images may not be in their layer contents. . A container is a read-write layer which is a child of an image's top layer, along with information which the library can manage for the convenience of its caller. This information typically includes configuration information for running the specific container. Multiple containers can be derived from a single image. . Layers, images, and containers are represented primarily by 32 character hexadecimal IDs, but items of each kind can also have one or more arbitrary names attached to them, which the library will automatically resolve to IDs when they are passed in to API calls which expect IDs. . The library can store what it calls metadata for each of these types of items. This is expected to be a small piece of data, since it is cached in memory and stored along with the library's own bookkeeping information. . Additionally, the library can store one or more of what it calls big data for images and containers. This is a named chunk of larger data, which is only in memory when it is being read from or being written to its own disk file.
Bug#921949: ITP: golang-github-containers-storage --
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: golang-github-containers-storage Version : 1.5-1 Upstream Author : * URL : https://github.com/containers/storage * License : Apache-2.0 Programming Lang: Go Description : Go library for handling how containers are stored on disk 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. Suggestions for improvements of the package description would be much appreciated. storage is a Go library which aims to provide methods for storing filesystem layers, container images, and containers. A containers-storage CLI wrapper is also included for manual and scripting use. . Operations which use VMs expect to launch them using 'vagrant', defaulting to using its 'libvirt' provider. The boxes used are also available for the 'virtualbox' provider, and can be selected by setting $VAGRANT_PROVIDER to 'virtualbox' before kicking off the build. . The library manages three types of items: layers, images, and containers. . A layer is a copy-on-write filesystem which is notionally stored as a set of changes relative to its parent layer, if it has one. A given layer can only have one parent, but any layer can be the parent of multiple layers. Layers which are parents of other layers should be treated as read-only. . An image is a reference to a particular layer (its top layer), along with other information which the library can manage for the convenience of its caller. This information typically includes configuration templates for running a binary contained within the image's layers, and may include cryptographic signatures. Multiple images can reference the same layer, as the differences between two images may not be in their layer contents. . A container is a read-write layer which is a child of an image's top layer, along with information which the library can manage for the convenience of its caller. This information typically includes configuration information for running the specific container. Multiple containers can be derived from a single image. . Layers, images, and containers are represented primarily by 32 character hexadecimal IDs, but items of each kind can also have one or more arbitrary names attached to them, which the library will automatically resolve to IDs when they are passed in to API calls which expect IDs. . The library can store what it calls metadata for each of these types of items. This is expected to be a small piece of data, since it is cached in memory and stored along with the library's own bookkeeping information. . Additionally, the library can store one or more of what it calls big data for images and containers. This is a named chunk of larger data, which is only in memory when it is being read from or being written to its own disk file.
Bug#921949: ITP: golang-github-containers-storage --
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: golang-github-containers-storage Version : 1.5-1 Upstream Author : * URL : https://github.com/containers/storage * License : Apache-2.0 Programming Lang: Go Description : Go library for handling how containers are stored on disk 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. Suggestions for improvements of the package description would be much appreciated. storage is a Go library which aims to provide methods for storing filesystem layers, container images, and containers. A containers-storage CLI wrapper is also included for manual and scripting use. . Operations which use VMs expect to launch them using 'vagrant', defaulting to using its 'libvirt' provider. The boxes used are also available for the 'virtualbox' provider, and can be selected by setting $VAGRANT_PROVIDER to 'virtualbox' before kicking off the build. . The library manages three types of items: layers, images, and containers. . A layer is a copy-on-write filesystem which is notionally stored as a set of changes relative to its parent layer, if it has one. A given layer can only have one parent, but any layer can be the parent of multiple layers. Layers which are parents of other layers should be treated as read-only. . An image is a reference to a particular layer (its top layer), along with other information which the library can manage for the convenience of its caller. This information typically includes configuration templates for running a binary contained within the image's layers, and may include cryptographic signatures. Multiple images can reference the same layer, as the differences between two images may not be in their layer contents. . A container is a read-write layer which is a child of an image's top layer, along with information which the library can manage for the convenience of its caller. This information typically includes configuration information for running the specific container. Multiple containers can be derived from a single image. . Layers, images, and containers are represented primarily by 32 character hexadecimal IDs, but items of each kind can also have one or more arbitrary names attached to them, which the library will automatically resolve to IDs when they are passed in to API calls which expect IDs. . The library can store what it calls metadata for each of these types of items. This is expected to be a small piece of data, since it is cached in memory and stored along with the library's own bookkeeping information. . Additionally, the library can store one or more of what it calls big data for images and containers. This is a named chunk of larger data, which is only in memory when it is being read from or being written to its own disk file.
Accepted restic 0.9.4+ds-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 09 Feb 2019 18:53:40 -0500 Source: restic Binary: restic Architecture: source Version: 0.9.4+ds-2 Distribution: unstable Urgency: medium Maintainer: Debian Go Packaging Team Changed-By: Reinhard Tartler Description: restic - backup program with multiple revisions, encryption and more Closes: 905149 921849 Changes: restic (0.9.4+ds-2) unstable; urgency=medium . * Team upload * Bug fix: restic 0.9.4 `-q` outputs `open repository` (Closes: #921849) * Add recommends on fuse (Closes: #905149) Checksums-Sha1: f551cb8116f4e71269753494637d055d4ba2999d 2998 restic_0.9.4+ds-2.dsc 1c8bce4b742b3d954007457b6e1c07c7b6adf0ff 16364 restic_0.9.4+ds-2.debian.tar.xz Checksums-Sha256: 86891c768cd04cfcbd205d05d699c44a976bb61e54c76ef21b0f263e349f1c26 2998 restic_0.9.4+ds-2.dsc 54b558685ae5a84632defc008a9d745b234d6984326b06e49e0668861056d1ff 16364 restic_0.9.4+ds-2.debian.tar.xz Files: 4464c83435ce65b4fb01d845dba4183b 2998 utils optional restic_0.9.4+ds-2.dsc 91219804e445d6e36e329622393b8530 16364 utils optional restic_0.9.4+ds-2.debian.tar.xz -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEEMN59F2OrlFLH4IJQSadpd5QoJssFAlxgGsUUHHNpcmV0YXJ0 QHRhdXdhcmUuZGUACgkQSadpd5QoJsvNeA//YvvkydvPA9lvVIzazKDbqGcZ5bfC dHUSYAvYglNTtTSAosY8YmoRKfMYSXBwy0rgYr0Inl+jBe0m+IqGTK7dbq1tI0oC dgrd7oXRvakRBEnADPK8vBOwF8IQWLgWLl2/fUyeOAjEdo0BL+lyY4qG7t7M0epM n1TBxuvrG6+hv1kxBw5m2SC7jYTPSU/J8sTVmngX4RX8qyOcBqv29fdG8/ZBElaW KPW4YCOyZQuNPCV1Wnz+Gury82BqVM13oB4BsxA+yBf99QPpTe9D6khYau3GI51q olnj6zkkO/KHyJMGKTlDjoZKMtdDJqrJVAVehgsDcWUcIGn1QXzGn5OGyUhs3jhe QQHSJNy1polfN/Ux84v8jq5jhUevtyAGEkeB0oZYGjeDtBqFXPuL94IsZwgPkEOd o2IhO1pbXBfghhIzdJPfXrvf+Al2MA5l5IlBDashA3fLVnr7ng5sNueDcq75VXgi o5Wz8/FZxPARZcBJgMLLiGVC6envf8EvleIbF3w4BtfzhUSZ/VPv1WfRuXw5d6ZG qXmK8Y3YH15VPOjHB1RriNgckgkiZ5pbM7ODW17ZIIFFAx5Yyqlt/6aS346S+cZR 2UVhKSnZUhl/5yvHDkeqDMSdb2edeidBmsJkBxmNBTdiG0olZnPdnF5HIwd2lknY 8dXypLGJhfFMxls= =W9IM -END PGP SIGNATURE-
[Bug 1341307] Re: fs2ram places /var/cache on tmpfs, Breaks unrelated packages
** Changed in: fs2ram (Ubuntu) Status: Invalid => New ** Changed in: software-center (Ubuntu) Status: Invalid => New ** Changed in: vdradmin (Ubuntu) Status: Invalid => New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1341307 Title: fs2ram places /var/cache on tmpfs, Breaks unrelated packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/fs2ram/+bug/1341307/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1341307] Re: fs2ram places /var/cache on tmpfs, Breaks unrelated packages
Nathan, could you please elaborate why you marked this bug as invalid? What makes you think this was fixed? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1341307 Title: fs2ram places /var/cache on tmpfs, Breaks unrelated packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/fs2ram/+bug/1341307/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[pkg-go] Bug#921849: restic 0.9.4 `-q` outputs `open repository`
Package: restic Version: 0.9.4+ds-1 Severity: important Tags: upstream When used for instance in a cron job for backup, I would get emails that have this content: /etc/cron.hourly/backup_restic: open repository open repository open repository This has been reported upstream at: https://github.com/restic/restic/issues/2140 The fix is straight-forward: https://github.com/restic/restic/commit/60c7020bcb3be64dc1131a8564a7818898a50c83 It seems there is no upstream release with this fix yet. I'd recommend to backport this upstream patch until 0.9.5 -- 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) Versions of packages restic depends on: ii libc6 2.24-11+deb9u3 restic recommends no packages. Versions of packages restic suggests: ii libjs-jquery 3.1.1-2 ii libjs-underscore 1.8.3~dfsg-1 -- no debconf information ___ 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#921849: restic 0.9.4 `-q` outputs `open repository`
Package: restic Version: 0.9.4+ds-1 Severity: important Tags: upstream When used for instance in a cron job for backup, I would get emails that have this content: /etc/cron.hourly/backup_restic: open repository open repository open repository This has been reported upstream at: https://github.com/restic/restic/issues/2140 The fix is straight-forward: https://github.com/restic/restic/commit/60c7020bcb3be64dc1131a8564a7818898a50c83 It seems there is no upstream release with this fix yet. I'd recommend to backport this upstream patch until 0.9.5 -- 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) Versions of packages restic depends on: ii libc6 2.24-11+deb9u3 restic recommends no packages. Versions of packages restic suggests: ii libjs-jquery 3.1.1-2 ii libjs-underscore 1.8.3~dfsg-1 -- no debconf information
Accepted golang-github-pquerna-ffjson 0.0~git20181028.e517b90-1 (source amd64 all) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 14 Jan 2019 17:31:56 -0500 Source: golang-github-pquerna-ffjson Binary: ffjson golang-github-pquerna-ffjson-dev Architecture: source amd64 all Version: 0.0~git20181028.e517b90-1 Distribution: unstable Urgency: medium Maintainer: Reinhard Tartler Changed-By: Reinhard Tartler Description: ffjson - faster JSON serialization for Go golang-github-pquerna-ffjson-dev - faster JSON serialization for Go Closes: 919278 Changes: golang-github-pquerna-ffjson (0.0~git20181028.e517b90-1) unstable; urgency=medium . * Initial release (Closes: #919278) Checksums-Sha1: aafc3ada1b15c2f72691c8095c9f29ecc942c2c5 2472 golang-github-pquerna-ffjson_0.0~git20181028.e517b90-1.dsc b4fe28f0773a277a31b15a2832126b427eb4f45a 75136 golang-github-pquerna-ffjson_0.0~git20181028.e517b90.orig.tar.xz e70034ee9a058c653d561adc0bfb5c45ab3734bb 2424 golang-github-pquerna-ffjson_0.0~git20181028.e517b90-1.debian.tar.xz 6165973b9f3360ffc94792b96d1479f78038e184 1112404 ffjson_0.0~git20181028.e517b90-1_amd64.deb 71f3cfd423612621ecc12edb06871ff741d5c3a0 70796 golang-github-pquerna-ffjson-dev_0.0~git20181028.e517b90-1_all.deb c8221f5f14aa178b72b95d7b2dfc8d20b4d7858f 6898 golang-github-pquerna-ffjson_0.0~git20181028.e517b90-1_amd64.buildinfo Checksums-Sha256: e4bfea57f8c11c5e8634955b44672326823c6a7860fc4c89aec6bd3d0a91b429 2472 golang-github-pquerna-ffjson_0.0~git20181028.e517b90-1.dsc 2cd556fcfc0a352ecd4ddfb910a336f9cbb1908342e5ce87f2fdbd8ab115c2e3 75136 golang-github-pquerna-ffjson_0.0~git20181028.e517b90.orig.tar.xz 8345c95af6aedfba28ef211edc39545cbf462cd7707d431544a5c8a4fa4e1926 2424 golang-github-pquerna-ffjson_0.0~git20181028.e517b90-1.debian.tar.xz 5df39a74e06887b882f2a69f6f93c69e77a501a0c643bf845d55f09d4a1df189 1112404 ffjson_0.0~git20181028.e517b90-1_amd64.deb 46a8cbf483f923e411f769e0b9763826a38f08a6558363bdd4859dfba6ca4e99 70796 golang-github-pquerna-ffjson-dev_0.0~git20181028.e517b90-1_all.deb b6cbcdf8f38b191aa91de59ab808f0ac7b5cae6390a2d921ebbe037aff4d52bb 6898 golang-github-pquerna-ffjson_0.0~git20181028.e517b90-1_amd64.buildinfo Files: 826a7e73b6350251865db153ba18e295 2472 devel optional golang-github-pquerna-ffjson_0.0~git20181028.e517b90-1.dsc 82e531211780e16f67587186af6c3833 75136 devel optional golang-github-pquerna-ffjson_0.0~git20181028.e517b90.orig.tar.xz d9f788f4dcbe61a1a41f165243c3d79d 2424 devel optional golang-github-pquerna-ffjson_0.0~git20181028.e517b90-1.debian.tar.xz 479f6934949dbebe4094e62509509f42 1112404 devel optional ffjson_0.0~git20181028.e517b90-1_amd64.deb da99c6f83dd4b111cec5f09c957a1231 70796 devel optional golang-github-pquerna-ffjson-dev_0.0~git20181028.e517b90-1_all.deb 286fe03b8828139e31857faeb7ed291f 6898 devel optional golang-github-pquerna-ffjson_0.0~git20181028.e517b90-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE6n5rckvJ+/LRcetya3IL6cXPbZ4FAlxaSXgACgkQa3IL6cXP bZ4IkhAAztnveDfSrWG0PHbFCj4MdsuAjYYJv61W2cHjFSU5uMVkVlIKiNIxI9Hu oR+BjLXNUnoqKY25wnxb0H/uHLYrKvwwdE16FiU7/ipzqL3d2F1avl2J0V3u5MBF 8TEtCgA/PYPOHudwHki9DQ6JA+xEkaVM4rPPBQSIYJaTYR1SjwvodsuFwYU1laHm 7C3e9dcNM6+mFYLC97LOMl2mqITUpa0jKgXdMli0rwjtkf5aP5hi8VAPcynJ42Zw N7IhjFA9AorChrDCXY1zi6OdvHKK1od7UhGvJfHvsQDBwUvnm6RW7OTSMHsaQLh3 sIb6FhURoQ43xBc8MzW0GNGXujJkPyHzrZLgNgibYSBa98EZJ3f8T52VWevA4CKx tWeDeWGd2Ji9rIbpqZurEG7pwCihfm6ueOKYZvsSDHBaEZIxqXViqAxxsh4ChwMK 5Aluy/+0aa06W73+SpubtpolaZztVv+fCvgZxNSNAfst+H6vPTWFncDqrlr+JgMm +Ftop2YuhtLmftahQ2xsN8O5wCTvPr83iam55WQSrwDuJIj0DKbH0Z1W5wFSOJ5y /4MDaHxSnINzEPwi5zK1YojNR5jwaaKYiFhVuCXGXRkB5gAMgS9bL++r6CLfNCOI aPNTT5FtAr8zy99hMayXJ9ifdNK4+lsKsl/y+ej87T4Uz/gcNgY= =9S3A -END PGP SIGNATURE-
Accepted slirp4netns 0.2.1-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 27 Jan 2019 10:43:49 -0500 Source: slirp4netns Binary: slirp4netns Architecture: source Version: 0.2.1-1 Distribution: unstable Urgency: medium Maintainer: Reinhard Tartler Changed-By: Reinhard Tartler Description: slirp4netns - User-mode networking for unprivileged network namespaces Changes: slirp4netns (0.2.1-1) unstable; urgency=medium . * New upstream release (Fixes: CVE-2019-6778) Checksums-Sha1: e78aa8a209dd8e2bfba4d747a91ba6cd4defcbf6 2087 slirp4netns_0.2.1-1.dsc 9281be14b2c04b3412e03c08fd9c98a3234bc7b2 136425 slirp4netns_0.2.1.orig.tar.gz 6d35ece9d6dfcd13d3dc5f1a5c2852efd73defb7 3908 slirp4netns_0.2.1-1.debian.tar.xz Checksums-Sha256: 824684c7ff583adcd1391e2d43076a5d40d6ff0e44079770bc3f2cf921e208b6 2087 slirp4netns_0.2.1-1.dsc 1a9681d5926365e8d60bd804c71733c05f8b44fd20393bf2f2b2d1ee1ea8517c 136425 slirp4netns_0.2.1.orig.tar.gz 2b78c282bfce7e948ff63f048318aa4a4f77c7690f3abb277bd6fa8598393e83 3908 slirp4netns_0.2.1-1.debian.tar.xz Files: f0551d6d47e4d8dc5f5f2d9489d8baaa 2087 misc optional slirp4netns_0.2.1-1.dsc 99a63581c0a8d4108299f7c9cb61ac11 136425 misc optional slirp4netns_0.2.1.orig.tar.gz c827c7d31f39c3ebb4c28f8aeb1a7a73 3908 misc optional slirp4netns_0.2.1-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQJIBAEBCAAyFiEE6n5rckvJ+/LRcetya3IL6cXPbZ4FAlxN0yMUHHNpcmV0YXJ0 QHRhdXdhcmUuZGUACgkQa3IL6cXPbZ5HRhAAuI5S1qLJUCLvBqVdc5rhmXBiwOWx UXOlqpQ53QOhW3Nz4i9CTHI923jci+HlJdLx8kuLzvA8gRTagq5V8NHUkl/gE5Bm IGFDRq9sFYJJJLEevjS+ceadVkVWUlqYoe5Hcmp/ZWdLvzqB39m021MJ9iSqZsgw v2Jfd7qdqBh97bK5dAApMHh0NiucyKPgG7r5BiQCt72c7wDLCUkpG/+EydzbSjew +hjSXSgat8hLfEKbU4eDOJe3cnl8mZ0vmkYqNSH+xppF5ykbJTWaaVGbO8yMqAQ4 YR7ZajWMnOjAe2TN1dnVpVKHwxBP0ZZm19MgMmTo+BbQimfnBMvP/3TRzk2s+v20 HltwzQ/5xNp1+LHP66TZ1pZb8/IBEorYEto+t9wS1A3ZZnbW2a9u+CUsSjJp4BUL Tfp05SWtusF6BkOXfJcb6+tG90Qz1jasBxPjYoOigh3mbu2uF7+ZQPKrpEVqeXLf j9u+GOZ7Y04UJ7BBQ7+pun6pT1ODfqil7cKNZcJegZ272o+WyrN0JFt9sT6T8Y9d umWMH43i2WES9oH4oppNa5wu7mjMHXyTeWsIkxfXE8bVdE/xt0jndfimlTOmkAKI VRFeONqgyxmX8r/xT3FgAtdRQM+9Hp4vO7FwHDJA5wbqCE5hNpIUG2oVKXtjyWnR wf7YYBy8hfsWOKE= =4PUw -END PGP SIGNATURE-
Bug#893227: libbluray FTBFS with openjdk-9
Hi Adrian, On Wed, Jan 23, 2019 at 12:54 PM Adrian Bunk wrote: > Due to popcon (and reverse dependencies) libbluray is a key package > that won't be autoremoved (otherwise it would have been autoremoved > from buster 9 months ago). > That's good to know, thanks for pointing it out. > A lowered severity only hides the problem, and the later it gets brought > up the fewer changes are permitted for fixing - until the end of February > you could even upload a new upstream version, but after that it will be > unlikely that this will be approved by the release team. > Well, the question is whether a new upstream version becomes available in time. The current version does simply not work at all with OpenJDK11. Given that we need a new upstream release, which I expect to introduce significant changes, we may run into trouble with qualifying for a "soft-freeze" update. It seems safer to upload (and test, i.e., have it migrated to testing), way before Feb 12 2019. The libbluray-bdj binary package has no reverse dependencies, > so removing it might be a Plan B if no better option would > be available. > I just looked at the code, and it doesn't look like it is possible to build it without OpenJDK-8 at all. There are files unconditionally built that #include . You might be suggesting to use OpenJDK-8 to build, but "simply" not ship the libbluray-bdj package. That would effectively drop support for BD menus from Debian, which is why I wouldn't consider this as a viable plan B. -- regards, Reinhard
Bug#893227: libbluray FTBFS with openjdk-9
Hi Adrian, On Wed, Jan 23, 2019 at 12:54 PM Adrian Bunk wrote: > Due to popcon (and reverse dependencies) libbluray is a key package > that won't be autoremoved (otherwise it would have been autoremoved > from buster 9 months ago). > That's good to know, thanks for pointing it out. > A lowered severity only hides the problem, and the later it gets brought > up the fewer changes are permitted for fixing - until the end of February > you could even upload a new upstream version, but after that it will be > unlikely that this will be approved by the release team. > Well, the question is whether a new upstream version becomes available in time. The current version does simply not work at all with OpenJDK11. Given that we need a new upstream release, which I expect to introduce significant changes, we may run into trouble with qualifying for a "soft-freeze" update. It seems safer to upload (and test, i.e., have it migrated to testing), way before Feb 12 2019. The libbluray-bdj binary package has no reverse dependencies, > so removing it might be a Plan B if no better option would > be available. > I just looked at the code, and it doesn't look like it is possible to build it without OpenJDK-8 at all. There are files unconditionally built that #include . You might be suggesting to use OpenJDK-8 to build, but "simply" not ship the libbluray-bdj package. That would effectively drop support for BD menus from Debian, which is why I wouldn't consider this as a viable plan B. -- regards, Reinhard
Bug#893227: libbluray FTBFS with openjdk-9
On Tue, Jan 22, 2019 at 5:34 PM Emmanuel Bourg wrote: > Le 22/01/2019 à 23:26, Reinhard Tartler a écrit : > > > Since openjdk-8 is going to be kept in Buster, I don't think > > we need to keep this bug at RC severity. I'm concerned that keeping > > this bug at RC severity might risk having libbluray being removed > > from testing, which I don't think is in the best interest of our > > users. > > Well, the issue remains critical, because the package doesn't work with > the default JRE the users are going to use in Buster. OpenJDK 8 is not > to be used at runtime in Buster. > > I agree that fixing this is a priority. I promise to upload it to Debian as soon as a fix becomes available (and I get aware of it). -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#893227: libbluray FTBFS with openjdk-9
On Tue, Jan 22, 2019 at 5:34 PM Emmanuel Bourg wrote: > Le 22/01/2019 à 23:26, Reinhard Tartler a écrit : > > > Since openjdk-8 is going to be kept in Buster, I don't think > > we need to keep this bug at RC severity. I'm concerned that keeping > > this bug at RC severity might risk having libbluray being removed > > from testing, which I don't think is in the best interest of our > > users. > > Well, the issue remains critical, because the package doesn't work with > the default JRE the users are going to use in Buster. OpenJDK 8 is not > to be used at runtime in Buster. > > I agree that fixing this is a priority. I promise to upload it to Debian as soon as a fix becomes available (and I get aware of it). -- regards, Reinhard
Bug#893227: libbluray FTBFS with openjdk-9
Control: severity -1 important On Tue, Jan 22, 2019 at 7:48 AM Emmanuel Bourg wrote: > OpenJDK 8 will be kept in Buster but it should be used in exceptional > cases (for example the lombok package requires both OpenJDK 8 and 11 to > build). The default Java runtime for Buster is OpenJDK 11 and the > packages have to work properly with it. > Thank you for this clarification. I agree that we should switch to OpenJDK 11 as soon as there is an upstream version available that allows this. Since openjdk-8 is going to be kept in Buster, I don't think we need to keep this bug at RC severity. I'm concerned that keeping this bug at RC severity might risk having libbluray being removed from testing, which I don't think is in the best interest of our users. -- regards, Reinhard
Bug#893227: libbluray FTBFS with openjdk-9
Control: severity -1 important On Tue, Jan 22, 2019 at 7:48 AM Emmanuel Bourg wrote: > OpenJDK 8 will be kept in Buster but it should be used in exceptional > cases (for example the lombok package requires both OpenJDK 8 and 11 to > build). The default Java runtime for Buster is OpenJDK 11 and the > packages have to work properly with it. > Thank you for this clarification. I agree that we should switch to OpenJDK 11 as soon as there is an upstream version available that allows this. Since openjdk-8 is going to be kept in Buster, I don't think we need to keep this bug at RC severity. I'm concerned that keeping this bug at RC severity might risk having libbluray being removed from testing, which I don't think is in the best interest of our users. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#893227: libbluray FTBFS with openjdk-9
Control: severity -1 important On Tue, Jan 22, 2019 at 7:48 AM Emmanuel Bourg wrote: > OpenJDK 8 will be kept in Buster but it should be used in exceptional > cases (for example the lombok package requires both OpenJDK 8 and 11 to > build). The default Java runtime for Buster is OpenJDK 11 and the > packages have to work properly with it. > Thank you for this clarification. I agree that we should switch to OpenJDK 11 as soon as there is an upstream version available that allows this. Since openjdk-8 is going to be kept in Buster, I don't think we need to keep this bug at RC severity. I'm concerned that keeping this bug at RC severity might risk having libbluray being removed from testing, which I don't think is in the best interest of our users. -- regards, Reinhard
Bug#893227: libbluray FTBFS with openjdk-9
Hi Petri, The schedule for Debian can be seen at https://wiki.debian.org/DebianBuster: - 2014-11-09: Distribution codename announced <https://lists.debian.org/debian-devel-announce/2014/11/msg5.html> - 2017-06-17: Stretch <https://wiki.debian.org/DebianStretch> is released, and buster becomes testing <https://wiki.debian.org/DebianTesting> - 2019-01-12: Transition freeze (announced <https://release.debian.org/buster/freeze_policy.html>) - 2019-02-12: Soft freeze - 2019-03-12: Full freeze So assuming the new libblueray doesn't require changes in depending packages we have until Feburary 12 to upload (AND TEST) an updated package. Hi Emmanuel, You may or may not remember, the Debian Multimedia team has been asked earlier last year to look into getting libbluray to work with newer JDKs. There is some progress, but apparently we are just not quite there yet, please see Petri's message below. Can you please give us an update on the roadmap for Java? What's the status on removing openjdk-8 from buster? Best, -rt On Tue, Jan 22, 2019 at 3:02 AM Petri Hintukainen wrote: > Hello, > > On Wed, Jan 16, 2019 at 7:14 AM Reinhard Tartler wrote: > > Looking at the commit history, it seems that there have been some > > changes wrt java > > compatibility, mostly by you. I wonder whether you'd expect libbluray > > to work with > > openjdk-11. If not, is this something on your roadmap, or do you > > consider this a > > stretch goal for the forseeable future? > > Build issues should be fixed in git. OpenJDK 11 can be used to build > the package, and resulting Java binary code is compatible with OpenJDK > 6...11. > > There are still few runtime issues, so libbluray does not try to load > JVM 9 ... 11 yet. But these remaining issues are more or less trivial, > and just need some testing. > > I've switched to use OpenJDK 11. OpenJDK 9 and 10 are still more or > less untested, but 11 seems more important version to support. > > What kind of schedule do you have ? We could have libbluray release > with OpenJDK 11 support in couple of weeks. Even earlier if we fix the > remaining issues and OpenJDK 9/10 issues in later releases. Anyway, I'd > expect some new issues when people start using libbluray with OpenJDK > 9..11. > > - Petri > > > -- regards, Reinhard
Bug#893227: libbluray FTBFS with openjdk-9
Hi Petri, The schedule for Debian can be seen at https://wiki.debian.org/DebianBuster: - 2014-11-09: Distribution codename announced <https://lists.debian.org/debian-devel-announce/2014/11/msg5.html> - 2017-06-17: Stretch <https://wiki.debian.org/DebianStretch> is released, and buster becomes testing <https://wiki.debian.org/DebianTesting> - 2019-01-12: Transition freeze (announced <https://release.debian.org/buster/freeze_policy.html>) - 2019-02-12: Soft freeze - 2019-03-12: Full freeze So assuming the new libblueray doesn't require changes in depending packages we have until Feburary 12 to upload (AND TEST) an updated package. Hi Emmanuel, You may or may not remember, the Debian Multimedia team has been asked earlier last year to look into getting libbluray to work with newer JDKs. There is some progress, but apparently we are just not quite there yet, please see Petri's message below. Can you please give us an update on the roadmap for Java? What's the status on removing openjdk-8 from buster? Best, -rt On Tue, Jan 22, 2019 at 3:02 AM Petri Hintukainen wrote: > Hello, > > On Wed, Jan 16, 2019 at 7:14 AM Reinhard Tartler wrote: > > Looking at the commit history, it seems that there have been some > > changes wrt java > > compatibility, mostly by you. I wonder whether you'd expect libbluray > > to work with > > openjdk-11. If not, is this something on your roadmap, or do you > > consider this a > > stretch goal for the forseeable future? > > Build issues should be fixed in git. OpenJDK 11 can be used to build > the package, and resulting Java binary code is compatible with OpenJDK > 6...11. > > There are still few runtime issues, so libbluray does not try to load > JVM 9 ... 11 yet. But these remaining issues are more or less trivial, > and just need some testing. > > I've switched to use OpenJDK 11. OpenJDK 9 and 10 are still more or > less untested, but 11 seems more important version to support. > > What kind of schedule do you have ? We could have libbluray release > with OpenJDK 11 support in couple of weeks. Even earlier if we fix the > remaining issues and OpenJDK 9/10 issues in later releases. Anyway, I'd > expect some new issues when people start using libbluray with OpenJDK > 9..11. > > - Petri > > > -- regards, Reinhard
Bug#893227: libbluray FTBFS with openjdk-9
Hi Petri, The schedule for Debian can be seen at https://wiki.debian.org/DebianBuster: - 2014-11-09: Distribution codename announced <https://lists.debian.org/debian-devel-announce/2014/11/msg5.html> - 2017-06-17: Stretch <https://wiki.debian.org/DebianStretch> is released, and buster becomes testing <https://wiki.debian.org/DebianTesting> - 2019-01-12: Transition freeze (announced <https://release.debian.org/buster/freeze_policy.html>) - 2019-02-12: Soft freeze - 2019-03-12: Full freeze So assuming the new libblueray doesn't require changes in depending packages we have until Feburary 12 to upload (AND TEST) an updated package. Hi Emmanuel, You may or may not remember, the Debian Multimedia team has been asked earlier last year to look into getting libbluray to work with newer JDKs. There is some progress, but apparently we are just not quite there yet, please see Petri's message below. Can you please give us an update on the roadmap for Java? What's the status on removing openjdk-8 from buster? Best, -rt On Tue, Jan 22, 2019 at 3:02 AM Petri Hintukainen wrote: > Hello, > > On Wed, Jan 16, 2019 at 7:14 AM Reinhard Tartler wrote: > > Looking at the commit history, it seems that there have been some > > changes wrt java > > compatibility, mostly by you. I wonder whether you'd expect libbluray > > to work with > > openjdk-11. If not, is this something on your roadmap, or do you > > consider this a > > stretch goal for the forseeable future? > > Build issues should be fixed in git. OpenJDK 11 can be used to build > the package, and resulting Java binary code is compatible with OpenJDK > 6...11. > > There are still few runtime issues, so libbluray does not try to load > JVM 9 ... 11 yet. But these remaining issues are more or less trivial, > and just need some testing. > > I've switched to use OpenJDK 11. OpenJDK 9 and 10 are still more or > less untested, but 11 seems more important version to support. > > What kind of schedule do you have ? We could have libbluray release > with OpenJDK 11 support in couple of weeks. Even earlier if we fix the > remaining issues and OpenJDK 9/10 issues in later releases. Anyway, I'd > expect some new issues when people start using libbluray with OpenJDK > 9..11. > > - Petri > > > -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#900900: ITP: oci-image-tools -- OCI image tooling
Hi Dmitry, For your convenience, I've implemented option c) below and pushed it to salsa. I chose that option because it is the easiest to override. Please let me know if this solution is acceptable to you, and whether you would feel strongly against me (re-)uploading it for you. Best, -rt On Thu, Jan 10, 2019 at 6:29 AM Reinhard Tartler wrote: > > > To make progress on the debian packaging, I see three options: > > a) Wait for upstream to make a release (cf. > https://github.com/opencontainers/image-tools/pull/200) > b) upload with an epoc > c) upload as 1.0.0~rc2+really.rc1-1 > > Given that option a) didn't work out for over half a year, > I'd suggest to proceed with option b) or c). > > Dmitry, what do you think? > > -rt > > -- regards, Reinhard
Bug#900900: ITP: oci-image-tools -- OCI image tooling
Hi Dmitry, For your convenience, I've implemented option c) below and pushed it to salsa. I chose that option because it is the easiest to override. Please let me know if this solution is acceptable to you, and whether you would feel strongly against me (re-)uploading it for you. Best, -rt On Thu, Jan 10, 2019 at 6:29 AM Reinhard Tartler wrote: > > > To make progress on the debian packaging, I see three options: > > a) Wait for upstream to make a release (cf. > https://github.com/opencontainers/image-tools/pull/200) > b) upload with an epoc > c) upload as 1.0.0~rc2+really.rc1-1 > > Given that option a) didn't work out for over half a year, > I'd suggest to proceed with option b) or c). > > Dmitry, what do you think? > > -rt > > -- regards, Reinhard
Bug#898689: ITP: golang-github-ostreedev-ostree-go -- Golang bindings for httt://github.com/ostreedev/ostree
Hi Juan, Thank you for your work on the package. I'm happy to sponsor uploads to Debian for you as necessary. Did you see my question in my previous email regarding whether skopeo also works with the sjoerdsimons fork that we currently have in Debian? If it would, I think Debian would be better of with a single copy in the archive. Let me know what you think. On Thu, Jan 17, 2019 at 9:39 AM Juan Picca wrote: > Hi Reinhard. > > As commented previously, I update the package to the version currently > used by skopeo (56f3a63). > If you can upload the files tell me and i send you the build results. > If not please give me some time to find a sponsor to upload the package. > > Regards, > JMPC > -- regards, Reinhard
Bug#898689: ITP: golang-github-ostreedev-ostree-go -- Golang bindings for httt://github.com/ostreedev/ostree
Hi Juan, Thank you for your work on the package. I'm happy to sponsor uploads to Debian for you as necessary. Did you see my question in my previous email regarding whether skopeo also works with the sjoerdsimons fork that we currently have in Debian? If it would, I think Debian would be better of with a single copy in the archive. Let me know what you think. On Thu, Jan 17, 2019 at 9:39 AM Juan Picca wrote: > Hi Reinhard. > > As commented previously, I update the package to the version currently > used by skopeo (56f3a63). > If you can upload the files tell me and i send you the build results. > If not please give me some time to find a sponsor to upload the package. > > Regards, > JMPC > -- regards, Reinhard
Bug#893227: libbluray FTBFS with openjdk-9
Hi Petri,
I'm following up on a question that Sebatian (CC'ed) asked on the mailing
list last march [1].
The issue is that Debian intends to drop openjdk-8 in favor of openjdk-11,
and we as package
maintainers of libbluray are asked to look into this transition. Your
response back then
was that there are non-trivial changes to the code necessary to make this
work.
Looking at the commit history, it seems that there have been some changes
wrt java
compatibility, mostly by you. I wonder whether you'd expect libbluray to
work with
openjdk-11. If not, is this something on your roadmap, or do you consider
this a
stretch goal for the forseeable future?
Please let me know what your thoughts on this issue are..
Best,
-rt
[1]
https://mailman.videolan.org/pipermail/libbluray-devel/2018-March/002890.html
On Sat, Mar 17, 2018 at 9:15 AM Adrian Bunk wrote:
> Source: libbluray
> Version: 1:1.0.2-2
> Severity: serious
>
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libbluray.html
>
> ...
>
> compile:
> [javac] /build/1st/libbluray-1.0.2/src/libbluray/bdj/build.xml:24:
> warning: 'includeantruntime' was not set, defaulting to
> build.sysclasspath=last; set to false for repeatable builds
> [javac] Using javac -source 1.4 is no longer supported, switching to
> 1.6
> [javac] Using javac -target 1.4 is no longer supported, switching to
> 1.6
> [javac] Compiling 664 source files to
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/build
> [javac] warning: [options] bootstrap class path not set in conjunction
> with -source 1.6
> [javac] warning: [options] source value 1.6 is obsolete and will be
> removed in a future release
> [javac] warning: [options] target value 1.6 is obsolete and will be
> removed in a future release
> [javac] warning: [options] To suppress warnings about obsolete
> options, use -Xlint:-options.
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java-j2se/java/awt/peer/BDFramePeer.java:176:
> error: package sun.awt.CausedFocusEvent does not exist
> [javac] public boolean requestFocus(Component c, boolean a,
> boolean b, long l, sun.awt.CausedFocusEvent.Cause d) {
> [javac]
> ^
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java/org/blurayx/s3d/ti/StereoscopicCodingType.java:37:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] type =
> (CodingType)constructor.newInstance(new String[] { "MPEG4_MVC_VIDEO" });
> [javac]
> ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java/org/blurayx/uhd/ti/UHDCodingType.java:38:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] type =
> (CodingType)constructor.newInstance(new String[] { "HEVC_VIDEO" });
> [javac]
> ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java/org/videolan/BDJSecurityManager.java:81:
> warning: [removal] classDepth(String) in SecurityManager has been
> deprecated and marked for removal
> [javac] if
> (classDepth("javax.crypto.JceSecurityManager") < 3) {
> [javac] ^
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java/org/videolan/BDJSecurityManager.java:88:
> warning: [removal] classDepth(String) in SecurityManager has been
> deprecated and marked for removal
> [javac] if (classDepth("org.videolan.Libbluray") == 3)
> {
> [javac] ^
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java/org/videolan/BDJSecurityManager.java:97:
> warning: [removal] classDepth(String) in SecurityManager has been
> deprecated and marked for removal
> [javac] if (classDepth("sun.awt.AWTAutoShutdown") > 0) {
> [javac] ^
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java/org/videolan/BDJSecurityManager.java:222:
> warning: [removal] checkSystemClipboardAccess() in SecurityManager has been
> deprecated and marked for removal
> [javac] public void checkSystemClipboardAccess() {
> [javac] ^
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java-j2se/java/io/BDFileSystemImpl.java:21:
> error: BDFileSystemImpl is not abstract and does not override abstract
> method getNameMax(String) in FileSystem
> [javac] class BDFileSystemImpl extends BDFileSystem {
> [javac] ^
> [javac] Note: Some input files use or override a deprecated API.
> [javac] Note: Recompile with -Xlint:deprecation for details.
> [javac] Note: Some input files use unchecked or unsafe
Bug#893227: libbluray FTBFS with openjdk-9
Hi Petri,
I'm following up on a question that Sebatian (CC'ed) asked on the mailing
list last march [1].
The issue is that Debian intends to drop openjdk-8 in favor of openjdk-11,
and we as package
maintainers of libbluray are asked to look into this transition. Your
response back then
was that there are non-trivial changes to the code necessary to make this
work.
Looking at the commit history, it seems that there have been some changes
wrt java
compatibility, mostly by you. I wonder whether you'd expect libbluray to
work with
openjdk-11. If not, is this something on your roadmap, or do you consider
this a
stretch goal for the forseeable future?
Please let me know what your thoughts on this issue are..
Best,
-rt
[1]
https://mailman.videolan.org/pipermail/libbluray-devel/2018-March/002890.html
On Sat, Mar 17, 2018 at 9:15 AM Adrian Bunk wrote:
> Source: libbluray
> Version: 1:1.0.2-2
> Severity: serious
>
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libbluray.html
>
> ...
>
> compile:
> [javac] /build/1st/libbluray-1.0.2/src/libbluray/bdj/build.xml:24:
> warning: 'includeantruntime' was not set, defaulting to
> build.sysclasspath=last; set to false for repeatable builds
> [javac] Using javac -source 1.4 is no longer supported, switching to
> 1.6
> [javac] Using javac -target 1.4 is no longer supported, switching to
> 1.6
> [javac] Compiling 664 source files to
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/build
> [javac] warning: [options] bootstrap class path not set in conjunction
> with -source 1.6
> [javac] warning: [options] source value 1.6 is obsolete and will be
> removed in a future release
> [javac] warning: [options] target value 1.6 is obsolete and will be
> removed in a future release
> [javac] warning: [options] To suppress warnings about obsolete
> options, use -Xlint:-options.
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java-j2se/java/awt/peer/BDFramePeer.java:176:
> error: package sun.awt.CausedFocusEvent does not exist
> [javac] public boolean requestFocus(Component c, boolean a,
> boolean b, long l, sun.awt.CausedFocusEvent.Cause d) {
> [javac]
> ^
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java/org/blurayx/s3d/ti/StereoscopicCodingType.java:37:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] type =
> (CodingType)constructor.newInstance(new String[] { "MPEG4_MVC_VIDEO" });
> [javac]
> ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java/org/blurayx/uhd/ti/UHDCodingType.java:38:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] type =
> (CodingType)constructor.newInstance(new String[] { "HEVC_VIDEO" });
> [javac]
> ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java/org/videolan/BDJSecurityManager.java:81:
> warning: [removal] classDepth(String) in SecurityManager has been
> deprecated and marked for removal
> [javac] if
> (classDepth("javax.crypto.JceSecurityManager") < 3) {
> [javac] ^
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java/org/videolan/BDJSecurityManager.java:88:
> warning: [removal] classDepth(String) in SecurityManager has been
> deprecated and marked for removal
> [javac] if (classDepth("org.videolan.Libbluray") == 3)
> {
> [javac] ^
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java/org/videolan/BDJSecurityManager.java:97:
> warning: [removal] classDepth(String) in SecurityManager has been
> deprecated and marked for removal
> [javac] if (classDepth("sun.awt.AWTAutoShutdown") > 0) {
> [javac] ^
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java/org/videolan/BDJSecurityManager.java:222:
> warning: [removal] checkSystemClipboardAccess() in SecurityManager has been
> deprecated and marked for removal
> [javac] public void checkSystemClipboardAccess() {
> [javac] ^
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java-j2se/java/io/BDFileSystemImpl.java:21:
> error: BDFileSystemImpl is not abstract and does not override abstract
> method getNameMax(String) in FileSystem
> [javac] class BDFileSystemImpl extends BDFileSystem {
> [javac] ^
> [javac] Note: Some input files use or override a deprecated API.
> [javac] Note: Recompile with -Xlint:deprecation for details.
> [javac] Note: Some input files use unchecked or unsafe
Bug#893227: libbluray FTBFS with openjdk-9
Hi Petri,
I'm following up on a question that Sebatian (CC'ed) asked on the mailing
list last march [1].
The issue is that Debian intends to drop openjdk-8 in favor of openjdk-11,
and we as package
maintainers of libbluray are asked to look into this transition. Your
response back then
was that there are non-trivial changes to the code necessary to make this
work.
Looking at the commit history, it seems that there have been some changes
wrt java
compatibility, mostly by you. I wonder whether you'd expect libbluray to
work with
openjdk-11. If not, is this something on your roadmap, or do you consider
this a
stretch goal for the forseeable future?
Please let me know what your thoughts on this issue are..
Best,
-rt
[1]
https://mailman.videolan.org/pipermail/libbluray-devel/2018-March/002890.html
On Sat, Mar 17, 2018 at 9:15 AM Adrian Bunk wrote:
> Source: libbluray
> Version: 1:1.0.2-2
> Severity: serious
>
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libbluray.html
>
> ...
>
> compile:
> [javac] /build/1st/libbluray-1.0.2/src/libbluray/bdj/build.xml:24:
> warning: 'includeantruntime' was not set, defaulting to
> build.sysclasspath=last; set to false for repeatable builds
> [javac] Using javac -source 1.4 is no longer supported, switching to
> 1.6
> [javac] Using javac -target 1.4 is no longer supported, switching to
> 1.6
> [javac] Compiling 664 source files to
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/build
> [javac] warning: [options] bootstrap class path not set in conjunction
> with -source 1.6
> [javac] warning: [options] source value 1.6 is obsolete and will be
> removed in a future release
> [javac] warning: [options] target value 1.6 is obsolete and will be
> removed in a future release
> [javac] warning: [options] To suppress warnings about obsolete
> options, use -Xlint:-options.
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java-j2se/java/awt/peer/BDFramePeer.java:176:
> error: package sun.awt.CausedFocusEvent does not exist
> [javac] public boolean requestFocus(Component c, boolean a,
> boolean b, long l, sun.awt.CausedFocusEvent.Cause d) {
> [javac]
> ^
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java/org/blurayx/s3d/ti/StereoscopicCodingType.java:37:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] type =
> (CodingType)constructor.newInstance(new String[] { "MPEG4_MVC_VIDEO" });
> [javac]
> ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java/org/blurayx/uhd/ti/UHDCodingType.java:38:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] type =
> (CodingType)constructor.newInstance(new String[] { "HEVC_VIDEO" });
> [javac]
> ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java/org/videolan/BDJSecurityManager.java:81:
> warning: [removal] classDepth(String) in SecurityManager has been
> deprecated and marked for removal
> [javac] if
> (classDepth("javax.crypto.JceSecurityManager") < 3) {
> [javac] ^
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java/org/videolan/BDJSecurityManager.java:88:
> warning: [removal] classDepth(String) in SecurityManager has been
> deprecated and marked for removal
> [javac] if (classDepth("org.videolan.Libbluray") == 3)
> {
> [javac] ^
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java/org/videolan/BDJSecurityManager.java:97:
> warning: [removal] classDepth(String) in SecurityManager has been
> deprecated and marked for removal
> [javac] if (classDepth("sun.awt.AWTAutoShutdown") > 0) {
> [javac] ^
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java/org/videolan/BDJSecurityManager.java:222:
> warning: [removal] checkSystemClipboardAccess() in SecurityManager has been
> deprecated and marked for removal
> [javac] public void checkSystemClipboardAccess() {
> [javac] ^
> [javac]
> /build/1st/libbluray-1.0.2/src/libbluray/bdj/java-j2se/java/io/BDFileSystemImpl.java:21:
> error: BDFileSystemImpl is not abstract and does not override abstract
> method getNameMax(String) in FileSystem
> [javac] class BDFileSystemImpl extends BDFileSystem {
> [javac] ^
> [javac] Note: Some input files use or override a deprecated API.
> [javac] Note: Recompile with -Xlint:deprecation for details.
> [javac] Note: Some input files use unchecked or unsafe
Accepted fuse-overlayfs 0.3-1 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 15 Jan 2019 17:21:58 -0500 Source: fuse-overlayfs Binary: fuse-overlayfs Architecture: source amd64 Version: 0.3-1 Distribution: unstable Urgency: medium Maintainer: Reinhard Tartler Changed-By: Reinhard Tartler Description: fuse-overlayfs - Implementation of overlay+shiftfs in FUSE for rootless containers Changes: fuse-overlayfs (0.3-1) unstable; urgency=medium . * New upstream version 0.3 Checksums-Sha1: 5160e771f69e7c9744cfb28e0e818a5b1d0c78e5 1954 fuse-overlayfs_0.3-1.dsc bc958e36a9cfa32c820b166a365460952e0ece6a 77515 fuse-overlayfs_0.3.orig.tar.gz 8d46da599afa2e4af7038dfafb4d02999c4fbbec 1648 fuse-overlayfs_0.3-1.debian.tar.xz 34d4722280e844f52daf0b2b7b357bc6b982008f 81424 fuse-overlayfs-dbgsym_0.3-1_amd64.deb 596173ab2b50f16eb1ea5d3f473fda198fda0933 6424 fuse-overlayfs_0.3-1_amd64.buildinfo 55505fca0b8b15c1ce83ec04d37d3c27096a5273 26204 fuse-overlayfs_0.3-1_amd64.deb Checksums-Sha256: f85cb313ed71f7d4684c6b361f03602539e06bdf4a137ca59df9509e9dab1800 1954 fuse-overlayfs_0.3-1.dsc 9d6ffafcfb5038426f830c8b1346947d71482f7fa9a9681edebecc162c01c448 77515 fuse-overlayfs_0.3.orig.tar.gz 9ade3a2ec029e5bf45de58ecb9300d94b4f875dcd750cd65afd35028a1925ce0 1648 fuse-overlayfs_0.3-1.debian.tar.xz 4163a3c6ce17ddd5e794a118ab886fd7ead0945354996b99bcc03450b23325d4 81424 fuse-overlayfs-dbgsym_0.3-1_amd64.deb db76c9bf4ec3f06ccd5ee72a606f2f79f0566d8e031026d2f6658136a605b093 6424 fuse-overlayfs_0.3-1_amd64.buildinfo 8e77aa360c916031164a7aad847543123ac0b7a4548a2aacfec027279624f53d 26204 fuse-overlayfs_0.3-1_amd64.deb Files: 09e98dd239a60d7990d7db36e052674a 1954 misc optional fuse-overlayfs_0.3-1.dsc b51db9df094de8d4b477e6fc84007a97 77515 misc optional fuse-overlayfs_0.3.orig.tar.gz 6d30ec6d7f6e40b9fdd20d7440e8a712 1648 misc optional fuse-overlayfs_0.3-1.debian.tar.xz 1af1a3e903788b1ddb3260e6d29e7221 81424 debug optional fuse-overlayfs-dbgsym_0.3-1_amd64.deb 8e9643117ec5bc074e2a3e57df9f8e11 6424 misc optional fuse-overlayfs_0.3-1_amd64.buildinfo 98a5b24920cb3778812055493696398b 26204 misc optional fuse-overlayfs_0.3-1_amd64.deb -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEEMN59F2OrlFLH4IJQSadpd5QoJssFAlw+XaUUHHNpcmV0YXJ0 QHRhdXdhcmUuZGUACgkQSadpd5QoJsuEFxAAqhXNiz1R6d9yrpSVxSWO8BlEMPdD QAC91/dmpVpC7RmWpn0nQd6s+mXX0M+OFdlV9zcLPC9MCkuSLRCVZj6E+BK19xb6 pZUmXQmSDAd8c+VP/nKEmCiKih/rt6/TDf/+kMNthKrrW3rEU28K66vZiCZ4D7Ee 8nNZXGZ4YNV/DRHQ0+XrxKSVsu5DsN+Co2XGVd1xLQphpxqQ7p2IK3PFsdDmWRC9 Qd8d4vQViNz6Xt1bg0avx3aZJVap1bE6vrGKPpAsgdaUmNXvG8ofnQ2xyCZIbgby RAtOFZjwFGCkorn4xuT5sOVik6MxG0iXpYYuzkazprNwsF0UnKeKFdUftnEMvS4Q WIKjffxBUAElQxJyw0Sn5JWfgYSRqHigqEX8F0F7KA8nZfWNFWZkM8WTMDd/L3an iJXEo7aFI2WcgM023wyAPq1EwNJOgh29HSDwtgS7eFQGDZkObRsAwXXXr1SUVCT2 iYRPuNZO/BFCLq9FooQ823fWRfhLC8eSL8RFNZW0ZcF1kqoIWLhdA4jQLOaVnNcJ hUimPqWX37Y1DeJ2FmhEkYHj9js5hljey27RZ1s9OxYgFD6GXQS3B1zI+KfkiEpl +U6ksOFYYHuD9YFdLSxhzBhS/Dp1ySH5K1F2UM96BOC3haeRSuGuVYeClc9Vd+mi Mg0V4Zim8mmcMUk= =Q/VY -END PGP SIGNATURE-
Bug#909032: Additional build failures
Seems that additional issues have shown up: dh_auto_configure make[1]: Leaving directory '/<>/cadvisor-0.27.1+dfsg2' dh_auto_build -a -O--buildsystem=golang -O--builddirectory=_build cd _build && go install -gcflags=all=\"-trimpath=/<>/cadvisor-0.27.1\+dfsg2/_build/src\" -asmflags=all=\"-trimpath=/<>/cadvisor-0.27.1\+dfsg2/_build/src\" -v -p 4 github.com/google/cadvisor github.com/google/cadvisor/api github.com/google/cadvisor/cache github.com/google/cadvisor/cache/memory github.com/google/cadvisor/client github.com/google/cadvisor/client/clientexample github.com/google/cadvisor/client/v2 github.com/google/cadvisor/collector github.com/google/cadvisor/container github.com/google/cadvisor/container/common github.com/google/cadvisor/container/crio github.com/google/cadvisor/container/docker github.com/google/cadvisor/container/libcontainer github.com/google/cadvisor/container/raw github.com/google/cadvisor/container/rkt github.com/google/cadvisor/container/systemd github.com/google/cadvisor/container/testing github.com/google/cadvisor/devicemapper github.com/google/cadvisor/devicemapper/fake github.com/google/cadvisor/events github.com/google/c advisor/fs github.com/google/cadvisor/healthz github.com/google/cadvisor/http github.com/google/cadvisor/http/mux github.com/google/cadvisor/info/v1 github.com/google/cadvisor/info/v1/test github.com/google/cadvisor/info/v2 github.com/google/cadvisor/integration/framework github.com/google/cadvisor/integration/runner github.com/google/cadvisor/integration/tests/api github.com/google/cadvisor/integration/tests/healthz github.com/google/cadvisor/machine github.com/google/cadvisor/manager github.com/google/cadvisor/manager/watcher github.com/google/cadvisor/manager/watcher/raw github.com/google/cadvisor/manager/watcher/rkt github.com/google/cadvisor/metrics github.com/google/cadvisor/pages github.com/google/cadvisor/pages/static github.com/google/cadvisor/storage github.com/google/cadvisor/storage/bigquery github.com/google/cadvisor/storage/bigquery/client github.com/google/cadvisor/storage/bigquery/client/example github.com/google/cadvisor/storage/elasticsearch github.com/google/cadvi sor/storage/influxdb github.com/google/cadvisor/storage/kafka github.com/google/cadvisor/storage/redis github.com/google/cadvisor/storage/statsd github.com/google/cadvisor/storage/statsd/client github.com/google/cadvisor/storage/stdout github.com/google/cadvisor/storage/test github.com/google/cadvisor/summary github.com/google/cadvisor/utils github.com/google/cadvisor/utils/cloudinfo github.com/google/cadvisor/utils/container github.com/google/cadvisor/utils/cpuload github.com/google/cadvisor/utils/cpuload/netlink github.com/google/cadvisor/utils/cpuload/netlink/example github.com/google/cadvisor/utils/docker github.com/google/cadvisor/utils/oomparser github.com/google/cadvisor/utils/oomparser/oomexample github.com/google/cadvisor/utils/procfs github.com/google/cadvisor/utils/sysfs github.com/google/cadvisor/utils/sysfs/fakesysfs github.com/google/cadvisor/utils/sysinfo github.com/google/cadvisor/utils/tail github.com/google/cadvisor/validate github.com/google/cadvisor/version githu b.com/google/cadvisor/zfs src/github.com/google/cadvisor/container/common/inotify_watcher.go:20:2: cannot find package "golang.org/x/exp/inotify" in any of: /<>/cadvisor-0.27.1+dfsg2/_build/src/github.com/google/cadvisor/vendor/golang.org/x/exp/inotify (vendor tree) /usr/lib/go-1.11/src/golang.org/x/exp/inotify (from $GOROOT) /<>/cadvisor-0.27.1+dfsg2/_build/src/golang.org/x/exp/inotify (from $GOPATH) dh_auto_build: cd _build && go install -gcflags=all=\"-trimpath=/<>/cadvisor-0.27.1\+dfsg2/_build/src\" -asmflags=all=\"-trimpath=/<>/cadvisor-0.27.1\+dfsg2/_build/src\" -v -p 4 github.com/google/cadvisor github.com/google/cadvisor/api github.com/google/cadvisor/cache github.com/google/cadvisor/cache/memory github.com/google/cadvisor/client github.com/google/cadvisor/client/clientexample github.com/google/cadvisor/client/v2 github.com/google/cadvisor/collector github.com/google/cadvisor/container github.com/google/cadvisor/container/common github.com/google/cadvisor/container/crio github.com/google/cadvisor/container/docker github.com/google/cadvisor/container/libcontainer github.com/google/cadvisor/container/raw github.com/google/cadvisor/container/rkt github.com/google/cadvisor/container/systemd github.com/google/cadvisor/container/testing github.com/google/cadvisor/devicemapper github.com/google/cadvisor/devicemapper/fake github.com/google/cadvisor/events githu b.com/google/cadvisor/fs github.com/google/cadvisor/healthz github.com/google/cadvisor/http github.com/google/cadvisor/http/mux github.com/google/cadvisor/info/v1 github.com/google/cadvisor/info/v1/test github.com/google/cadvisor/info/v2 github.com/google/cadvisor/integration/framework github.com/google/cadvisor/integration/runner
Bug#909032: Additional build failures
Seems that additional issues have shown up: dh_auto_configure make[1]: Leaving directory '/<>/cadvisor-0.27.1+dfsg2' dh_auto_build -a -O--buildsystem=golang -O--builddirectory=_build cd _build && go install -gcflags=all=\"-trimpath=/<>/cadvisor-0.27.1\+dfsg2/_build/src\" -asmflags=all=\"-trimpath=/<>/cadvisor-0.27.1\+dfsg2/_build/src\" -v -p 4 github.com/google/cadvisor github.com/google/cadvisor/api github.com/google/cadvisor/cache github.com/google/cadvisor/cache/memory github.com/google/cadvisor/client github.com/google/cadvisor/client/clientexample github.com/google/cadvisor/client/v2 github.com/google/cadvisor/collector github.com/google/cadvisor/container github.com/google/cadvisor/container/common github.com/google/cadvisor/container/crio github.com/google/cadvisor/container/docker github.com/google/cadvisor/container/libcontainer github.com/google/cadvisor/container/raw github.com/google/cadvisor/container/rkt github.com/google/cadvisor/container/systemd github.com/google/cadvisor/container/testing github.com/google/cadvisor/devicemapper github.com/google/cadvisor/devicemapper/fake github.com/google/cadvisor/events github.com/google/c advisor/fs github.com/google/cadvisor/healthz github.com/google/cadvisor/http github.com/google/cadvisor/http/mux github.com/google/cadvisor/info/v1 github.com/google/cadvisor/info/v1/test github.com/google/cadvisor/info/v2 github.com/google/cadvisor/integration/framework github.com/google/cadvisor/integration/runner github.com/google/cadvisor/integration/tests/api github.com/google/cadvisor/integration/tests/healthz github.com/google/cadvisor/machine github.com/google/cadvisor/manager github.com/google/cadvisor/manager/watcher github.com/google/cadvisor/manager/watcher/raw github.com/google/cadvisor/manager/watcher/rkt github.com/google/cadvisor/metrics github.com/google/cadvisor/pages github.com/google/cadvisor/pages/static github.com/google/cadvisor/storage github.com/google/cadvisor/storage/bigquery github.com/google/cadvisor/storage/bigquery/client github.com/google/cadvisor/storage/bigquery/client/example github.com/google/cadvisor/storage/elasticsearch github.com/google/cadvi sor/storage/influxdb github.com/google/cadvisor/storage/kafka github.com/google/cadvisor/storage/redis github.com/google/cadvisor/storage/statsd github.com/google/cadvisor/storage/statsd/client github.com/google/cadvisor/storage/stdout github.com/google/cadvisor/storage/test github.com/google/cadvisor/summary github.com/google/cadvisor/utils github.com/google/cadvisor/utils/cloudinfo github.com/google/cadvisor/utils/container github.com/google/cadvisor/utils/cpuload github.com/google/cadvisor/utils/cpuload/netlink github.com/google/cadvisor/utils/cpuload/netlink/example github.com/google/cadvisor/utils/docker github.com/google/cadvisor/utils/oomparser github.com/google/cadvisor/utils/oomparser/oomexample github.com/google/cadvisor/utils/procfs github.com/google/cadvisor/utils/sysfs github.com/google/cadvisor/utils/sysfs/fakesysfs github.com/google/cadvisor/utils/sysinfo github.com/google/cadvisor/utils/tail github.com/google/cadvisor/validate github.com/google/cadvisor/version githu b.com/google/cadvisor/zfs src/github.com/google/cadvisor/container/common/inotify_watcher.go:20:2: cannot find package "golang.org/x/exp/inotify" in any of: /<>/cadvisor-0.27.1+dfsg2/_build/src/github.com/google/cadvisor/vendor/golang.org/x/exp/inotify (vendor tree) /usr/lib/go-1.11/src/golang.org/x/exp/inotify (from $GOROOT) /<>/cadvisor-0.27.1+dfsg2/_build/src/golang.org/x/exp/inotify (from $GOPATH) dh_auto_build: cd _build && go install -gcflags=all=\"-trimpath=/<>/cadvisor-0.27.1\+dfsg2/_build/src\" -asmflags=all=\"-trimpath=/<>/cadvisor-0.27.1\+dfsg2/_build/src\" -v -p 4 github.com/google/cadvisor github.com/google/cadvisor/api github.com/google/cadvisor/cache github.com/google/cadvisor/cache/memory github.com/google/cadvisor/client github.com/google/cadvisor/client/clientexample github.com/google/cadvisor/client/v2 github.com/google/cadvisor/collector github.com/google/cadvisor/container github.com/google/cadvisor/container/common github.com/google/cadvisor/container/crio github.com/google/cadvisor/container/docker github.com/google/cadvisor/container/libcontainer github.com/google/cadvisor/container/raw github.com/google/cadvisor/container/rkt github.com/google/cadvisor/container/systemd github.com/google/cadvisor/container/testing github.com/google/cadvisor/devicemapper github.com/google/cadvisor/devicemapper/fake github.com/google/cadvisor/events githu b.com/google/cadvisor/fs github.com/google/cadvisor/healthz github.com/google/cadvisor/http github.com/google/cadvisor/http/mux github.com/google/cadvisor/info/v1 github.com/google/cadvisor/info/v1/test github.com/google/cadvisor/info/v2 github.com/google/cadvisor/integration/framework github.com/google/cadvisor/integration/runner
[pkg-go] Bug#909032: Additional build failures
Seems that additional issues have shown up: dh_auto_configure make[1]: Leaving directory '/<>/cadvisor-0.27.1+dfsg2' dh_auto_build -a -O--buildsystem=golang -O--builddirectory=_build cd _build && go install -gcflags=all=\"-trimpath=/<>/cadvisor-0.27.1\+dfsg2/_build/src\" -asmflags=all=\"-trimpath=/<>/cadvisor-0.27.1\+dfsg2/_build/src\" -v -p 4 github.com/google/cadvisor github.com/google/cadvisor/api github.com/google/cadvisor/cache github.com/google/cadvisor/cache/memory github.com/google/cadvisor/client github.com/google/cadvisor/client/clientexample github.com/google/cadvisor/client/v2 github.com/google/cadvisor/collector github.com/google/cadvisor/container github.com/google/cadvisor/container/common github.com/google/cadvisor/container/crio github.com/google/cadvisor/container/docker github.com/google/cadvisor/container/libcontainer github.com/google/cadvisor/container/raw github.com/google/cadvisor/container/rkt github.com/google/cadvisor/container/systemd github.com/google/cadvisor/container/testing github.com/google/cadvisor/devicemapper github.com/google/cadvisor/devicemapper/fake github.com/google/cadvisor/events github.com/google/c advisor/fs github.com/google/cadvisor/healthz github.com/google/cadvisor/http github.com/google/cadvisor/http/mux github.com/google/cadvisor/info/v1 github.com/google/cadvisor/info/v1/test github.com/google/cadvisor/info/v2 github.com/google/cadvisor/integration/framework github.com/google/cadvisor/integration/runner github.com/google/cadvisor/integration/tests/api github.com/google/cadvisor/integration/tests/healthz github.com/google/cadvisor/machine github.com/google/cadvisor/manager github.com/google/cadvisor/manager/watcher github.com/google/cadvisor/manager/watcher/raw github.com/google/cadvisor/manager/watcher/rkt github.com/google/cadvisor/metrics github.com/google/cadvisor/pages github.com/google/cadvisor/pages/static github.com/google/cadvisor/storage github.com/google/cadvisor/storage/bigquery github.com/google/cadvisor/storage/bigquery/client github.com/google/cadvisor/storage/bigquery/client/example github.com/google/cadvisor/storage/elasticsearch github.com/google/cadvi sor/storage/influxdb github.com/google/cadvisor/storage/kafka github.com/google/cadvisor/storage/redis github.com/google/cadvisor/storage/statsd github.com/google/cadvisor/storage/statsd/client github.com/google/cadvisor/storage/stdout github.com/google/cadvisor/storage/test github.com/google/cadvisor/summary github.com/google/cadvisor/utils github.com/google/cadvisor/utils/cloudinfo github.com/google/cadvisor/utils/container github.com/google/cadvisor/utils/cpuload github.com/google/cadvisor/utils/cpuload/netlink github.com/google/cadvisor/utils/cpuload/netlink/example github.com/google/cadvisor/utils/docker github.com/google/cadvisor/utils/oomparser github.com/google/cadvisor/utils/oomparser/oomexample github.com/google/cadvisor/utils/procfs github.com/google/cadvisor/utils/sysfs github.com/google/cadvisor/utils/sysfs/fakesysfs github.com/google/cadvisor/utils/sysinfo github.com/google/cadvisor/utils/tail github.com/google/cadvisor/validate github.com/google/cadvisor/version githu b.com/google/cadvisor/zfs src/github.com/google/cadvisor/container/common/inotify_watcher.go:20:2: cannot find package "golang.org/x/exp/inotify" in any of: /<>/cadvisor-0.27.1+dfsg2/_build/src/github.com/google/cadvisor/vendor/golang.org/x/exp/inotify (vendor tree) /usr/lib/go-1.11/src/golang.org/x/exp/inotify (from $GOROOT) /<>/cadvisor-0.27.1+dfsg2/_build/src/golang.org/x/exp/inotify (from $GOPATH) dh_auto_build: cd _build && go install -gcflags=all=\"-trimpath=/<>/cadvisor-0.27.1\+dfsg2/_build/src\" -asmflags=all=\"-trimpath=/<>/cadvisor-0.27.1\+dfsg2/_build/src\" -v -p 4 github.com/google/cadvisor github.com/google/cadvisor/api github.com/google/cadvisor/cache github.com/google/cadvisor/cache/memory github.com/google/cadvisor/client github.com/google/cadvisor/client/clientexample github.com/google/cadvisor/client/v2 github.com/google/cadvisor/collector github.com/google/cadvisor/container github.com/google/cadvisor/container/common github.com/google/cadvisor/container/crio github.com/google/cadvisor/container/docker github.com/google/cadvisor/container/libcontainer github.com/google/cadvisor/container/raw github.com/google/cadvisor/container/rkt github.com/google/cadvisor/container/systemd github.com/google/cadvisor/container/testing github.com/google/cadvisor/devicemapper github.com/google/cadvisor/devicemapper/fake github.com/google/cadvisor/events githu b.com/google/cadvisor/fs github.com/google/cadvisor/healthz github.com/google/cadvisor/http github.com/google/cadvisor/http/mux github.com/google/cadvisor/info/v1 github.com/google/cadvisor/info/v1/test github.com/google/cadvisor/info/v2 github.com/google/cadvisor/integration/framework github.com/google/cadvisor/integration/runner
Accepted golang-github-opencontainers-selinux 1.0.0-1 (all source) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 11 Jan 2019 16:53:23 -0500 Source: golang-github-opencontainers-selinux Binary: golang-github-opencontainers-selinux-dev Architecture: all source Version: 1.0.0-1 Distribution: experimental Urgency: medium Maintainer: Debian Go Packaging Team Changed-By: Reinhard Tartler Closes: 901745 Description: golang-github-opencontainers-selinux-dev - common selinux implementation Changes: golang-github-opencontainers-selinux (1.0.0-1) experimental; urgency=medium . * Team upload. . [ Alexandre Viau ] * Point Vcs-* urls to salsa.debian.org. . [ Dmitry Smirnov ] * Standards-Version: 4.1.4; Priority: optional. . [ Reinhard Tartler ] * New upstream version (Closes: #901745). Checksums-Sha1: 969aef11d1c7babe5bb664b87c194609e35ab953 2358 golang-github-opencontainers-selinux_1.0.0-1.dsc 47d6f5e21e613f9f64d6f5e15613f466abaeabaf 17931 golang-github-opencontainers-selinux_1.0.0.orig.tar.gz bc7704f14347601cc0c3fd38bd3c3a948b1478c8 2420 golang-github-opencontainers-selinux_1.0.0-1.debian.tar.xz dd5c5a0931a464f33d2343a2421a1dec176db686 12340 golang-github-opencontainers-selinux-dev_1.0.0-1_all.deb daf0f4948c7e991bedc4c04621e37b4370695bd9 5859 golang-github-opencontainers-selinux_1.0.0-1_amd64.buildinfo Checksums-Sha256: cc00d18e385c3cae07168ec16fdc0308ce0370dcaf4153f783da7b36c19f2b13 2358 golang-github-opencontainers-selinux_1.0.0-1.dsc 7f096eb89f056b602f82c8cfaba6979b2a1dc4e93da016ed97e6d85c5c039984 17931 golang-github-opencontainers-selinux_1.0.0.orig.tar.gz 540fb0e018a6955e4e690281249c7a0eed191fd80a0772d14bc16a730028539e 2420 golang-github-opencontainers-selinux_1.0.0-1.debian.tar.xz 9c408f326c131d7c92a6dd07aecdb4834fad1371b3ba409be683dc7a5429a649 12340 golang-github-opencontainers-selinux-dev_1.0.0-1_all.deb f671c6365589b51e78ea94d58084e9b11fcd7c4340bae843a7cd5e12820de159 5859 golang-github-opencontainers-selinux_1.0.0-1_amd64.buildinfo Files: bfc5a9319239707dda9478fc8f512c2c 2358 devel optional golang-github-opencontainers-selinux_1.0.0-1.dsc 2d4dc4064ad7db52a7542d839d462592 17931 devel optional golang-github-opencontainers-selinux_1.0.0.orig.tar.gz 08f74226bd509087ce760b08f2c7d878 2420 devel optional golang-github-opencontainers-selinux_1.0.0-1.debian.tar.xz 941c906f68b0ce06e3dbc6c0b7258816 12340 devel optional golang-github-opencontainers-selinux-dev_1.0.0-1_all.deb 19253bd41c19f36dc59952f72da7b613 5859 devel optional golang-github-opencontainers-selinux_1.0.0-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEEMN59F2OrlFLH4IJQSadpd5QoJssFAlw9T7YUHHNpcmV0YXJ0 QHRhdXdhcmUuZGUACgkQSadpd5QoJssj/g/+N0J7FWZgd/fR0lFdzTVlQC4d/jLH d6wucTu2zlwBuGJ/6AYB6mJ9k9Y5ea5fF6x4ycxBJHcYmTzDKawUclOcVwEcq/pE qSSDptFivuggnkVeOBtvfmIivXYwi81C/NYT5mxu8BV+Yd7NyWKzxkLjpg4r49D8 2YpJr/GtdQ7bhHewPyp3Wqz/bzI3Jn324tszavo5Dc/X28oC6rJyTAOwYOi4Ij08 ys8tj81aVas6toPMfrXpn9cye75QLT78llDEpCpMdLjLogYq47aCj1h8PnZda9Ia AfVI4117h/n/nykPvySHeAh0IEi/Nd8JnGoIQkvKGy3auy0T7G3HJl1A6BphoLj5 fYqES0RqLqhmKc692P2J0hnW5D0NjUcYwcz+032tlhLtLYMFiRKjRvXS1XPoxvGY MYxdfrjOL+4+zbYv2CLxzPkMvjTCF+q3gQJ8SlzI7v1BJ0IqLHAJ+SGA8/2zyJ+R Q7Ok/LA/KBKSbc9PepVWeIuZzupKxBCXRBaq4kSpkmiVHcppJkF6wGTr5xfLP4a2 p4DFXd++hroxZku65ya6qIe2phn2Qzi9gZer9uL4Rq+51vAXLuvIVZ/MOp1Q9/zb nuzs2JbKwFSHLysavkxp9wFdMnIsnMc8oBtWj6/LQDSWKi5yVAiqq3gzIpgvhSix L6QgZ2pswFIdk7s= =WYeZ -END PGP SIGNATURE-
Accepted golang-github-opencontainers-selinux 1.0.0-1 (all source) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 11 Jan 2019 16:53:23 -0500 Source: golang-github-opencontainers-selinux Binary: golang-github-opencontainers-selinux-dev Architecture: all source Version: 1.0.0-1 Distribution: experimental Urgency: medium Maintainer: Debian Go Packaging Team Changed-By: Reinhard Tartler Closes: 901745 Description: golang-github-opencontainers-selinux-dev - common selinux implementation Changes: golang-github-opencontainers-selinux (1.0.0-1) experimental; urgency=medium . * Team upload. . [ Alexandre Viau ] * Point Vcs-* urls to salsa.debian.org. . [ Dmitry Smirnov ] * Standards-Version: 4.1.4; Priority: optional. . [ Reinhard Tartler ] * New upstream version (Closes: #901745). Checksums-Sha1: 969aef11d1c7babe5bb664b87c194609e35ab953 2358 golang-github-opencontainers-selinux_1.0.0-1.dsc 47d6f5e21e613f9f64d6f5e15613f466abaeabaf 17931 golang-github-opencontainers-selinux_1.0.0.orig.tar.gz bc7704f14347601cc0c3fd38bd3c3a948b1478c8 2420 golang-github-opencontainers-selinux_1.0.0-1.debian.tar.xz dd5c5a0931a464f33d2343a2421a1dec176db686 12340 golang-github-opencontainers-selinux-dev_1.0.0-1_all.deb daf0f4948c7e991bedc4c04621e37b4370695bd9 5859 golang-github-opencontainers-selinux_1.0.0-1_amd64.buildinfo Checksums-Sha256: cc00d18e385c3cae07168ec16fdc0308ce0370dcaf4153f783da7b36c19f2b13 2358 golang-github-opencontainers-selinux_1.0.0-1.dsc 7f096eb89f056b602f82c8cfaba6979b2a1dc4e93da016ed97e6d85c5c039984 17931 golang-github-opencontainers-selinux_1.0.0.orig.tar.gz 540fb0e018a6955e4e690281249c7a0eed191fd80a0772d14bc16a730028539e 2420 golang-github-opencontainers-selinux_1.0.0-1.debian.tar.xz 9c408f326c131d7c92a6dd07aecdb4834fad1371b3ba409be683dc7a5429a649 12340 golang-github-opencontainers-selinux-dev_1.0.0-1_all.deb f671c6365589b51e78ea94d58084e9b11fcd7c4340bae843a7cd5e12820de159 5859 golang-github-opencontainers-selinux_1.0.0-1_amd64.buildinfo Files: bfc5a9319239707dda9478fc8f512c2c 2358 devel optional golang-github-opencontainers-selinux_1.0.0-1.dsc 2d4dc4064ad7db52a7542d839d462592 17931 devel optional golang-github-opencontainers-selinux_1.0.0.orig.tar.gz 08f74226bd509087ce760b08f2c7d878 2420 devel optional golang-github-opencontainers-selinux_1.0.0-1.debian.tar.xz 941c906f68b0ce06e3dbc6c0b7258816 12340 devel optional golang-github-opencontainers-selinux-dev_1.0.0-1_all.deb 19253bd41c19f36dc59952f72da7b613 5859 devel optional golang-github-opencontainers-selinux_1.0.0-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEEMN59F2OrlFLH4IJQSadpd5QoJssFAlw9T7YUHHNpcmV0YXJ0 QHRhdXdhcmUuZGUACgkQSadpd5QoJssj/g/+N0J7FWZgd/fR0lFdzTVlQC4d/jLH d6wucTu2zlwBuGJ/6AYB6mJ9k9Y5ea5fF6x4ycxBJHcYmTzDKawUclOcVwEcq/pE qSSDptFivuggnkVeOBtvfmIivXYwi81C/NYT5mxu8BV+Yd7NyWKzxkLjpg4r49D8 2YpJr/GtdQ7bhHewPyp3Wqz/bzI3Jn324tszavo5Dc/X28oC6rJyTAOwYOi4Ij08 ys8tj81aVas6toPMfrXpn9cye75QLT78llDEpCpMdLjLogYq47aCj1h8PnZda9Ia AfVI4117h/n/nykPvySHeAh0IEi/Nd8JnGoIQkvKGy3auy0T7G3HJl1A6BphoLj5 fYqES0RqLqhmKc692P2J0hnW5D0NjUcYwcz+032tlhLtLYMFiRKjRvXS1XPoxvGY MYxdfrjOL+4+zbYv2CLxzPkMvjTCF+q3gQJ8SlzI7v1BJ0IqLHAJ+SGA8/2zyJ+R Q7Ok/LA/KBKSbc9PepVWeIuZzupKxBCXRBaq4kSpkmiVHcppJkF6wGTr5xfLP4a2 p4DFXd++hroxZku65ya6qIe2phn2Qzi9gZer9uL4Rq+51vAXLuvIVZ/MOp1Q9/zb nuzs2JbKwFSHLysavkxp9wFdMnIsnMc8oBtWj6/LQDSWKi5yVAiqq3gzIpgvhSix L6QgZ2pswFIdk7s= =WYeZ -END PGP SIGNATURE-
Bug#919278: ITP: golang-github-pquerna-ffjson -- faster JSON serialization for Go
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: golang-github-pquerna-ffjson Version : 0.0~git20181028.e517b90-1 Upstream Author : Paul Querna * URL : https://github.com/pquerna/ffjson * License : Apache-2.0 Programming Lang: Go Description : faster JSON serialization for Go ffjson: faster JSON for Go Build Status (https://travis-ci.org/pquerna/ffjson) . ffjson generates static MarshalJSON and UnmarshalJSON functions for structures in Go. The generated functions reduce the reliance upon runtime reflection to do serialization and are generally 2 to 3 times faster. In cases where ffjson doesn't understand a Type involved, it falls back to encoding/json, meaning it is a safe drop in replacement. By using ffjson your JSON serialization just gets faster with no additional code changes. This package is going to be team maintained on salsa at https://salsa.debian.org/go-team/packages/golang-github-pquerna-ffjson This is my first golang package, so additional set of eyeballs would be appreciated. This package is a build-dependency of github.com/containers/image, which in turns is required for skopeo (#880199).
Bug#919278: ITP: golang-github-pquerna-ffjson -- faster JSON serialization for Go
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: golang-github-pquerna-ffjson Version : 0.0~git20181028.e517b90-1 Upstream Author : Paul Querna * URL : https://github.com/pquerna/ffjson * License : Apache-2.0 Programming Lang: Go Description : faster JSON serialization for Go ffjson: faster JSON for Go Build Status (https://travis-ci.org/pquerna/ffjson) . ffjson generates static MarshalJSON and UnmarshalJSON functions for structures in Go. The generated functions reduce the reliance upon runtime reflection to do serialization and are generally 2 to 3 times faster. In cases where ffjson doesn't understand a Type involved, it falls back to encoding/json, meaning it is a safe drop in replacement. By using ffjson your JSON serialization just gets faster with no additional code changes. This package is going to be team maintained on salsa at https://salsa.debian.org/go-team/packages/golang-github-pquerna-ffjson This is my first golang package, so additional set of eyeballs would be appreciated. This package is a build-dependency of github.com/containers/image, which in turns is required for skopeo (#880199).
Bug#919278: ITP: golang-github-pquerna-ffjson -- faster JSON serialization for Go
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: golang-github-pquerna-ffjson Version : 0.0~git20181028.e517b90-1 Upstream Author : Paul Querna * URL : https://github.com/pquerna/ffjson * License : Apache-2.0 Programming Lang: Go Description : faster JSON serialization for Go ffjson: faster JSON for Go Build Status (https://travis-ci.org/pquerna/ffjson) . ffjson generates static MarshalJSON and UnmarshalJSON functions for structures in Go. The generated functions reduce the reliance upon runtime reflection to do serialization and are generally 2 to 3 times faster. In cases where ffjson doesn't understand a Type involved, it falls back to encoding/json, meaning it is a safe drop in replacement. By using ffjson your JSON serialization just gets faster with no additional code changes. This package is going to be team maintained on salsa at https://salsa.debian.org/go-team/packages/golang-github-pquerna-ffjson This is my first golang package, so additional set of eyeballs would be appreciated. This package is a build-dependency of github.com/containers/image, which in turns is required for skopeo (#880199).
Accepted fuse-overlayfs 0.2-1 (source amd64) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 31 Dec 2018 07:19:58 -0500 Source: fuse-overlayfs Binary: fuse-overlayfs Architecture: source amd64 Version: 0.2-1 Distribution: unstable Urgency: medium Maintainer: Reinhard Tartler Changed-By: Reinhard Tartler Description: fuse-overlayfs - Implementation of overlay+shiftfs in FUSE for rootless containers Closes: 917889 Changes: fuse-overlayfs (0.2-1) unstable; urgency=medium . * Initial release (Closes: #917889) Checksums-Sha1: 75c172984880e84235bf309d878271e0a691143e 2072 fuse-overlayfs_0.2-1.dsc d62ada2b51279761808f9c65a69b474df90b163c 77234 fuse-overlayfs_0.2.orig.tar.gz 7bacb07dc00ed51d052c7d0687703586832a57c7 1596 fuse-overlayfs_0.2-1.debian.tar.xz f2efb62ccac5483adf6a4f45f79007f27b52a725 80032 fuse-overlayfs-dbgsym_0.2-1_amd64.deb eb9cb3f1628100c1a866fe5c9a8e471d9787ae27 6422 fuse-overlayfs_0.2-1_amd64.buildinfo 929f9040b6aede8bb48c6aa3abec464480d912ff 25852 fuse-overlayfs_0.2-1_amd64.deb Checksums-Sha256: f5fde1d429548238ab9ecbd07c68e5b2134522ae1899613f49c4732ea78aec8f 2072 fuse-overlayfs_0.2-1.dsc 380d57ac6ba8e4a4b8819b9bf453f20fdc14fecbea15b1f5709c237b76811c23 77234 fuse-overlayfs_0.2.orig.tar.gz 509c00035481162edb6ea38404bf92c3722d3673834646053161b9ca41383f56 1596 fuse-overlayfs_0.2-1.debian.tar.xz 4f97ae234e9799624ec96ff5fd9175201dc7e899b4a3a30d51f38449b9ec071f 80032 fuse-overlayfs-dbgsym_0.2-1_amd64.deb 7ebb2b1506ce4c38e70ac1a51c2d9d09099a2a145b2e4aa24c6018fe9944ce09 6422 fuse-overlayfs_0.2-1_amd64.buildinfo d4c1acaa81f779d8de144113685c4c29c20d104c53fcce5b676d90452b0b43b0 25852 fuse-overlayfs_0.2-1_amd64.deb Files: 5ed40441d830f145cd192f52399e1b51 2072 misc optional fuse-overlayfs_0.2-1.dsc 7f53fbb377803621deaeb9056cc776c7 77234 misc optional fuse-overlayfs_0.2.orig.tar.gz 64c18ea0ca9dfa2b2ed5f9eae31c8723 1596 misc optional fuse-overlayfs_0.2-1.debian.tar.xz 5b0c620d5a418091edcbcf395b7cec8c 80032 debug optional fuse-overlayfs-dbgsym_0.2-1_amd64.deb 2801a57fe9a6019af474b48a799f0509 6422 misc optional fuse-overlayfs_0.2-1_amd64.buildinfo 82daf614f1c654a22e3c4e1f9bacb970 25852 misc optional fuse-overlayfs_0.2-1_amd64.deb -BEGIN PGP SIGNATURE- iQJIBAEBCAAyFiEE6n5rckvJ+/LRcetya3IL6cXPbZ4FAlwre44UHHNpcmV0YXJ0 QHRhdXdhcmUuZGUACgkQa3IL6cXPbZ7KUBAAwpMeHiuWXidLIWv7o7lWL0Xu4Qjv ZVQF/Bai6K5OfAPJAQPm0u2SKiP15LTshTDq8kDvDSp5kfvjfPu9mJ9YWKgrOlCi d2u0jdQZ/oZNAQBIjEYWMfoG96UNiF/69DGlWhZ3ox091gI/Vx7OvHHPiEo6PaRA gaXZcIn0HNA0WdYYSYB3kAK1kx1DAuUR6yfVpJslmLMHdl68LP7mplXSKzxpBsiM 7fUJmUhITAVlJWiGNNht/Z1bb8QVPIYg2N+tAVqUQRjl4NtDwyLbi5kLXDlGeCn2 W6gGfZCG24Je17dFQ2Q4p6KNlhr8VsSrn2OxpP1fWhh6eca84IwoqLANYp2/bHHl TAS5SKEf+9l16N5drMiGGPfXN/g1ipVmioPiBzNVUHyNhmPNBUI74JPoTuZ9vn1h di03yCe8bdsSbbERFP/SrrZ99N1JCZ3p5IAYiSpIacREdTdzHucmzxTP0MZiyMpZ 0JcGNHyens0BJBotuUI81rc2bRwO40ikF64iwAIPIDt/ypiDlQyJq+CmMTGVq9qa 8it4GMSBjKV2N/HdwBdCz37Z05tpeWN914MbDreA3Te3jdYMd25aOxAwnsFBOAMu rDQTnBMXv6D6DZHVZKw9ldhDWiZi4nIGIfVWN7N6kyeWlEl5Rk0JXmtfubgaL0tO AJDbQOO2DMvk2AY= =Xo+b -END PGP SIGNATURE-
Accepted keepassx 2.0.3-2 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 12 Jan 2019 12:54:05 -0500 Source: keepassx Binary: keepassx Architecture: source amd64 Version: 2.0.3-2 Distribution: unstable Urgency: medium Maintainer: Reinhard Tartler Changed-By: Reinhard Tartler Description: keepassx - Cross Platform Password Manager Changes: keepassx (2.0.3-2) unstable; urgency=medium . * Acknowledge NMU * Bump standards version * Improve package description (Thanks to Bruno Kleinert!) Checksums-Sha1: dd42d461a03eb280ac680a26af19e7e344fcbba0 2112 keepassx_2.0.3-2.dsc 4cca538623dd3b4edeae74835175ea274d2dda08 84352 keepassx_2.0.3-2.debian.tar.xz 95135f208f68224d2277f41800809870de48e03c 6848828 keepassx-dbgsym_2.0.3-2_amd64.deb ec62c0b67a3d923e5e1726b195e0a739c5d60ac4 10282 keepassx_2.0.3-2_amd64.buildinfo 3990e6d4b42f9ecc7901b26259a8a770349e5e8a 511808 keepassx_2.0.3-2_amd64.deb Checksums-Sha256: 3a9a517c5e7537e334ddf3584bfa1e234fce576e942d1922d470914c7f7ad987 2112 keepassx_2.0.3-2.dsc e87619578098c60e37582c6be9394cbfbbac4445e4fa9cdc12c0d69934e3a2ce 84352 keepassx_2.0.3-2.debian.tar.xz 1219e1bf2010dba3537d88a2cb0993a22f3e2124fc3f85e62ec2df3342b5d44d 6848828 keepassx-dbgsym_2.0.3-2_amd64.deb 54dd1756e61c4a87042bd9b7f25e07ed4bf4d64d4e6933501928737eaef84743 10282 keepassx_2.0.3-2_amd64.buildinfo 8bb8569608ed8282263d5f38148fd62ae5be8038bb57d1a1ce048d05fe634ceb 511808 keepassx_2.0.3-2_amd64.deb Files: 41142e4a67f354375151738fd40b6b4b 2112 utils optional keepassx_2.0.3-2.dsc 420fdee895e9d9c48a74baa576cf4f4e 84352 utils optional keepassx_2.0.3-2.debian.tar.xz 746497d26d5af0234446d308a766423d 6848828 debug optional keepassx-dbgsym_2.0.3-2_amd64.deb 18dcfdada9c4faaebb03628f0253c100 10282 utils optional keepassx_2.0.3-2_amd64.buildinfo 12013f9a56375a12dac6537fc13df8cd 511808 utils optional keepassx_2.0.3-2_amd64.deb -BEGIN PGP SIGNATURE- iQJIBAEBCAAyFiEE6n5rckvJ+/LRcetya3IL6cXPbZ4FAlw6MYYUHHNpcmV0YXJ0 QHRhdXdhcmUuZGUACgkQa3IL6cXPbZ4FNxAAlLCj/A5laW7O/aAcCvtwaIatI6xm RlO+yWDhPc1lZYJefRidgdtiCJhPv5FnBvUlmTLbDLBI0JeEUmzgXfUmcUv3z180 /EEPOOqxQGx2fue6y/7XtTpLRnglGdZLYH8ChK89xaDAXKujnOw+VvcciyCv4Nqo wr1lBbB/SU0nTAZy9eri4MOp56t9Cju8D3ocGG37R00jjjaKCI4qnWlr5HkvDtCI M+A9Ik/id8Zc3+1j3RZsqAR4PXOIz2aFDXkmC0w6J78gs4rq0MiPeKT1Sx9cGdCI eK2EKApGe+BRyaGBIUsLa/gNBmKdqTRURVlflzGtG/kDDjrR0ku0PYQw7qSLR2P5 OIyFMObG9K1VFObTaoK5ZhtZcOnYMU+8rft/RyQm/N/jAfb9/TNjUtyh0BoH9PNx X8W+543eB4PONQJZcvL0I/wtneEkfAGhKUNty+jT60uY1JUR/MP/r037R+7CDDFc La+RrkNTnDMGgh4RgNo/d7z9qWEeeWUbO6vBfXw3VqH3zDl8DJgqnBq+SpKDOVqv EiK8+B/UVadJ0vyezlsb72/+Ta9BbKytRw5iYbs1/Vcbn+Bj1rLGxYgn4O3QIJ+o IC45KD+g996+8Y0yZG0Kp4WuLNRWG85wpPa1dKKOTzWMnndpaecSraT9wvDVXtaH SZ8mk/y/DvAQPqI= =b5e4 -END PGP SIGNATURE-
Bug#900900: ITP: oci-image-tools -- OCI image tooling
On Thu, Jan 10, 2019, 00:55 Dmitry Smirnov On Wednesday, 9 January 2019 11:04:26 PM AEDT Reinhard Tartler wrote: > > All in all, the package looks good for upload to me. May I ask where we > are > > with that? > > Wait a sec, did you check the following forwarded bug upstream? > > https://github.com/opencontainers/image-tools/issues/204 > > That's the problem. I've uploaded the package but it was rejected because > "newer" version is already in the archive... > Thanks for pointing to the bug. To make progress on the debian packaging, I see three options: a) Wait for upstream to make a release (cf. https://github.com/opencontainers/image-tools/pull/200) b) upload with an epoc c) upload as 1.0.0~rc2+really.rc1-1 Given that option a) didn't work out for over half a year, I'd suggest to proceed with option b) or c). Dmitry, what do you think? -rt
Bug#900900: ITP: oci-image-tools -- OCI image tooling
On Thu, Jan 10, 2019, 00:55 Dmitry Smirnov On Wednesday, 9 January 2019 11:04:26 PM AEDT Reinhard Tartler wrote: > > All in all, the package looks good for upload to me. May I ask where we > are > > with that? > > Wait a sec, did you check the following forwarded bug upstream? > > https://github.com/opencontainers/image-tools/issues/204 > > That's the problem. I've uploaded the package but it was rejected because > "newer" version is already in the archive... > Thanks for pointing to the bug. To make progress on the debian packaging, I see three options: a) Wait for upstream to make a release (cf. https://github.com/opencontainers/image-tools/pull/200) b) upload with an epoc c) upload as 1.0.0~rc2+really.rc1-1 Given that option a) didn't work out for over half a year, I'd suggest to proceed with option b) or c). Dmitry, what do you think? -rt
Bug#898689: ITP: golang-github-ostreedev-ostree-go -- Golang bindings for httt://github.com/ostreedev/ostree
Cool, thanks! On Wed, Jan 9, 2019 at 10:46 AM Juan Picca wrote: > Hi Reinhard. > > Currently ostree-go, commit d0388bd (master HEAD today) fails some tests: > > ``` > === RUN TestCommitTreeSuccess > --- FAIL: TestCommitTreeSuccess (0.11s) > commit_test.go:108: failed to tar populated dir: read > /tmp/otbuiltin-test-179055475/commit1: is a directory > === RUN TestCommitTreeParentSuccess > --- FAIL: TestCommitTreeParentSuccess (0.05s) > commit_test.go:169: failed to tar populated dir: read > /tmp/otbuiltin-test-662857270/commit1: is a directory > ``` > > My first intention was package all skopeo dependencies, then skopeo, > then upload all packages. > Sadly, it showed very ambitious and I can't had the time to do it. > > If i remember well, the version from 'Sjoerd Simons' pass all the tests. > Well, if skopeo works with the Sjoerd Simons version, maybe we don't need to package the original version at all? > > About the ITP, if help, i can update the version to the one used by > skopeo (currently 56f3a63, > https://github.com/containers/skopeo/blob/master/vendor.conf) and > exclude the failing tests. > I never had upload a package to debian, maybe you can do it from the > repository if time is pressing. > > That's not a problem, I'd be happy to help where I can. I noticed that there is no ITP for skopeo is #880199. Maybe you could update that ITP with an email about what dependencies are missing and where we are at packaging it? -- regards, Reinhard
Bug#898689: ITP: golang-github-ostreedev-ostree-go -- Golang bindings for httt://github.com/ostreedev/ostree
Cool, thanks! On Wed, Jan 9, 2019 at 10:46 AM Juan Picca wrote: > Hi Reinhard. > > Currently ostree-go, commit d0388bd (master HEAD today) fails some tests: > > ``` > === RUN TestCommitTreeSuccess > --- FAIL: TestCommitTreeSuccess (0.11s) > commit_test.go:108: failed to tar populated dir: read > /tmp/otbuiltin-test-179055475/commit1: is a directory > === RUN TestCommitTreeParentSuccess > --- FAIL: TestCommitTreeParentSuccess (0.05s) > commit_test.go:169: failed to tar populated dir: read > /tmp/otbuiltin-test-662857270/commit1: is a directory > ``` > > My first intention was package all skopeo dependencies, then skopeo, > then upload all packages. > Sadly, it showed very ambitious and I can't had the time to do it. > > If i remember well, the version from 'Sjoerd Simons' pass all the tests. > Well, if skopeo works with the Sjoerd Simons version, maybe we don't need to package the original version at all? > > About the ITP, if help, i can update the version to the one used by > skopeo (currently 56f3a63, > https://github.com/containers/skopeo/blob/master/vendor.conf) and > exclude the failing tests. > I never had upload a package to debian, maybe you can do it from the > repository if time is pressing. > > That's not a problem, I'd be happy to help where I can. I noticed that there is no ITP for skopeo is #880199. Maybe you could update that ITP with an email about what dependencies are missing and where we are at packaging it? -- regards, Reinhard
Re: Bug#898689: ITP: golang-github-ostreedev-ostree-go -- Golang bindings for httt://github.com/ostreedev/ostree
Cool, thanks! On Wed, Jan 9, 2019 at 10:46 AM Juan Picca wrote: > Hi Reinhard. > > Currently ostree-go, commit d0388bd (master HEAD today) fails some tests: > > ``` > === RUN TestCommitTreeSuccess > --- FAIL: TestCommitTreeSuccess (0.11s) > commit_test.go:108: failed to tar populated dir: read > /tmp/otbuiltin-test-179055475/commit1: is a directory > === RUN TestCommitTreeParentSuccess > --- FAIL: TestCommitTreeParentSuccess (0.05s) > commit_test.go:169: failed to tar populated dir: read > /tmp/otbuiltin-test-662857270/commit1: is a directory > ``` > > My first intention was package all skopeo dependencies, then skopeo, > then upload all packages. > Sadly, it showed very ambitious and I can't had the time to do it. > > If i remember well, the version from 'Sjoerd Simons' pass all the tests. > Well, if skopeo works with the Sjoerd Simons version, maybe we don't need to package the original version at all? > > About the ITP, if help, i can update the version to the one used by > skopeo (currently 56f3a63, > https://github.com/containers/skopeo/blob/master/vendor.conf) and > exclude the failing tests. > I never had upload a package to debian, maybe you can do it from the > repository if time is pressing. > > That's not a problem, I'd be happy to help where I can. I noticed that there is no ITP for skopeo is #880199. Maybe you could update that ITP with an email about what dependencies are missing and where we are at packaging it? -- regards, Reinhard
Bug#880199: Packaging blockers
Hi, I've looked at packaging skopeo as well, and according to the dh-make-golang tool, there are apparently 3 dependencies blocking this ITP: 2019/01/09 06:54:27 Build-Dependency "github.com/containers/storage" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control 2019/01/09 06:54:27 Build-Dependency "github.com/containers/image" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control 2019/01/09 06:54:27 Build-Dependency "github.com/opencontainers/image-tools" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control The latter one is #900900, the first two don't seem to be worked on yet. -- regards, Reinhard
Bug#880199: Packaging blockers
Hi, I've looked at packaging skopeo as well, and according to the dh-make-golang tool, there are apparently 3 dependencies blocking this ITP: 2019/01/09 06:54:27 Build-Dependency "github.com/containers/storage" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control 2019/01/09 06:54:27 Build-Dependency "github.com/containers/image" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control 2019/01/09 06:54:27 Build-Dependency "github.com/opencontainers/image-tools" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control The latter one is #900900, the first two don't seem to be worked on yet. -- regards, Reinhard
Bug#900900: ITP: oci-image-tools -- OCI image tooling
Hi Dmitry, I wonder where we are with this ITP about packaging oci-image-tools -- OCI image tooling. I've cloned salsa:go-team/packages/oci-image-tools and testbuilt it in a debian/unstable. Lintian output seems reasonable to me. So does debian/copyright. All in all, the package looks good for upload to me. May I ask where we are with that? -- regards, Reinhard
Bug#900900: ITP: oci-image-tools -- OCI image tooling
Hi Dmitry, I wonder where we are with this ITP about packaging oci-image-tools -- OCI image tooling. I've cloned salsa:go-team/packages/oci-image-tools and testbuilt it in a debian/unstable. Lintian output seems reasonable to me. So does debian/copyright. All in all, the package looks good for upload to me. May I ask where we are with that? -- regards, Reinhard
Bug#898689: ITP: golang-github-ostreedev-ostree-go -- Golang bindings for httt://github.com/ostreedev/ostree
Hi Juan, are you still working on this ITP? I was looking at skopeo as well, and stumpled upon this ITP. I noticed that you created a repository on salsa: https://salsa.debian.org/go-team/packages/golang-github-ostreedev-ostree-go This package never got uploaded. However, I also noticed that there is another packaging repo in salsa, which contains a similar package that did get uploaded: https://salsa.debian.org/go-team/packages/golang-github-sjoerdsimons-ostree-go https://tracker.debian.org/pkg/golang-github-sjoerdsimons-ostree-go I wonder what the relationship between these two are. It seems that the sjoerdsimons version does declare it satisfies the import of the github:ostreedev/ostree-go repo, which makes me believe it is a fork. If this is the case, can we consider this ITP abandoned and close it? I've also copied Alexandre and the debian-go mailing list for input how to proceed here. Thanks On Tue, May 15, 2018 at 3:57 AM Juan Picca wrote: > Package: wnpp > Severity: wishlist > Owner: Juan Picca > > * Package name: golang-github-ostreedev-ostree-go > Version : 0.0~git20171027.cb6250d-1 > Upstream Author : OSTree Project > * URL : https://github.com/ostreedev/ostree-go > * License : ISC > Programming Lang: Go > Description : Golang bindings for httt://github.com/ostreedev/ostree > > OSTree-Go Go bindings for OSTree. Find out more about OSTree here > (https://github.com/ostreedev/ostree) > > This package is a dependency for skopeo > (https://github.com/projectatomic/skopeo). > > -- regards, Reinhard
Bug#898689: ITP: golang-github-ostreedev-ostree-go -- Golang bindings for httt://github.com/ostreedev/ostree
Hi Juan, are you still working on this ITP? I was looking at skopeo as well, and stumpled upon this ITP. I noticed that you created a repository on salsa: https://salsa.debian.org/go-team/packages/golang-github-ostreedev-ostree-go This package never got uploaded. However, I also noticed that there is another packaging repo in salsa, which contains a similar package that did get uploaded: https://salsa.debian.org/go-team/packages/golang-github-sjoerdsimons-ostree-go https://tracker.debian.org/pkg/golang-github-sjoerdsimons-ostree-go I wonder what the relationship between these two are. It seems that the sjoerdsimons version does declare it satisfies the import of the github:ostreedev/ostree-go repo, which makes me believe it is a fork. If this is the case, can we consider this ITP abandoned and close it? I've also copied Alexandre and the debian-go mailing list for input how to proceed here. Thanks On Tue, May 15, 2018 at 3:57 AM Juan Picca wrote: > Package: wnpp > Severity: wishlist > Owner: Juan Picca > > * Package name: golang-github-ostreedev-ostree-go > Version : 0.0~git20171027.cb6250d-1 > Upstream Author : OSTree Project > * URL : https://github.com/ostreedev/ostree-go > * License : ISC > Programming Lang: Go > Description : Golang bindings for httt://github.com/ostreedev/ostree > > OSTree-Go Go bindings for OSTree. Find out more about OSTree here > (https://github.com/ostreedev/ostree) > > This package is a dependency for skopeo > (https://github.com/projectatomic/skopeo). > > -- regards, Reinhard
Bug#907632: [ppc64-el] Breaks building aspectc++
No problem at all. Thanks for taking care of the sync for me, Steve! Reinhard On January 2, 2019 2:30:50 PM EST, Steve Langasek wrote: >On Tue, Jan 01, 2019 at 04:32:38PM -0500, Reinhard Tartler wrote: >> On 12/25/18 11:53 AM, Steve Langasek wrote: >> > Package: aspectc++ >> > Version: 1:2.2+git20170823-7 >> > Followup-For: Bug #907632 >> > User: ubuntu-de...@lists.ubuntu.com >> > Usertags: origin-ubuntu disco ubuntu-patch >> > >> > Hello, >> > >> > Based on the bug history, I don't think this is a bug in gcc-8 but >in >> > aspectc++ (or in llvm), so I have reassigned. >> > >> > I have also refined the patch provided by Frédéric, to avoid >repetition in >> > the code; please find it attached. >> > >> > I have uploaded this patch to Ubuntu, where I confirm it fixes the >build >> > failure on ppc64el. > >> I've already incorporated Frederic's patch in aspectc++ >1:2.2+git20181008-2, >> which I've uploaded to unstable on Tue, 23 Oct 2018. > >> Maybe it would be appropriate to sync that version over to ubuntu? > >Indeed, sorry for overlooking, I missed this because there was an >Ubuntu >delta stuck in devel-proposed where I had previously tried to fix up >the >llvm-version-related FTBFS. I've synced this now and it has built fine >on >ppc64el. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#907632: [ppc64-el] Breaks building aspectc++
Hi Steve, On 12/25/18 11:53 AM, Steve Langasek wrote: > Package: aspectc++ > Version: 1:2.2+git20170823-7 > Followup-For: Bug #907632 > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu disco ubuntu-patch > > Hello, > > Based on the bug history, I don't think this is a bug in gcc-8 but in > aspectc++ (or in llvm), so I have reassigned. > > I have also refined the patch provided by Frédéric, to avoid repetition in > the code; please find it attached. > > I have uploaded this patch to Ubuntu, where I confirm it fixes the build > failure on ppc64el. > I've already incorporated Frederic's patch in aspectc++ 1:2.2+git20181008-2, which I've uploaded to unstable on Tue, 23 Oct 2018. Maybe it would be appropriate to sync that version over to ubuntu? Best, Reinhard
Accepted slirp4netns 0.1~git20181119.5e4789b-1 (source amd64) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 26 Dec 2018 09:52:59 -0500 Source: slirp4netns Binary: slirp4netns Architecture: source amd64 Version: 0.1~git20181119.5e4789b-1 Distribution: unstable Urgency: medium Maintainer: Reinhard Tartler Changed-By: Reinhard Tartler Description: slirp4netns - User-mode networking for unprivileged network namespaces Closes: 917337 Changes: slirp4netns (0.1~git20181119.5e4789b-1) unstable; urgency=medium . * Initial release (Closes: #917337) Checksums-Sha1: 97ef7eb8d6d31f663abed3ba5b09ed85cc914c15 2064 slirp4netns_0.1~git20181119.5e4789b-1.dsc 3f987fc08c87de864eb1135752eacec8279efaa5 99384 slirp4netns_0.1~git20181119.5e4789b.orig.tar.xz a638fb7fab30f124cf6af99f024ca5aa6647326f 3816 slirp4netns_0.1~git20181119.5e4789b-1.debian.tar.xz c7085919474bb673e18b108c0c9f683bf6c34526 168168 slirp4netns-dbgsym_0.1~git20181119.5e4789b-1_amd64.deb 1a4e3cb151eeb7f2cd332169a4a2d777e1f9d153 6194 slirp4netns_0.1~git20181119.5e4789b-1_amd64.buildinfo 4aac58a8f6f83240b5768f9f6bbddc5e605e54b9 44532 slirp4netns_0.1~git20181119.5e4789b-1_amd64.deb Checksums-Sha256: 10bdd024523846baafd7e7a8ac00599047dadc709dc6bf973bbb01ba5b88acbe 2064 slirp4netns_0.1~git20181119.5e4789b-1.dsc 0788fd68c5533ebf4ac21c249977ac312aa158c0e733fd103ce8aaa2ed68ab70 99384 slirp4netns_0.1~git20181119.5e4789b.orig.tar.xz d0ae6bd739a837f91397d6889e4b56465b2fc397bf9ef9e3be68f19d7adbe1b5 3816 slirp4netns_0.1~git20181119.5e4789b-1.debian.tar.xz 7df4bd30dcd41263de57564f1992d941a09ff15c6986ea1b14b3b0942e8ef9d7 168168 slirp4netns-dbgsym_0.1~git20181119.5e4789b-1_amd64.deb 7681ca5ca2540321905c5eb67d1c0dcbf77a120995af0d67fda8adf31596fc1a 6194 slirp4netns_0.1~git20181119.5e4789b-1_amd64.buildinfo 1019006cad617a5b2831f33db96cec31900fd6e7627cba79b8e424e47ad9b515 44532 slirp4netns_0.1~git20181119.5e4789b-1_amd64.deb Files: 292c595cf5fbb4a12d074ed7d3cc89b2 2064 misc optional slirp4netns_0.1~git20181119.5e4789b-1.dsc c894686dc64aaa9e15092dcee8ba4e74 99384 misc optional slirp4netns_0.1~git20181119.5e4789b.orig.tar.xz 0f3778fc91c98102bddb9024685cd1b3 3816 misc optional slirp4netns_0.1~git20181119.5e4789b-1.debian.tar.xz 4635b38f418448532e5d93ec685c2292 168168 debug optional slirp4netns-dbgsym_0.1~git20181119.5e4789b-1_amd64.deb d40411a3d32b9824bb189be827aac064 6194 misc optional slirp4netns_0.1~git20181119.5e4789b-1_amd64.buildinfo a6bb28402c49b66bbd50ffec50d8d2fb 44532 misc optional slirp4netns_0.1~git20181119.5e4789b-1_amd64.deb -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE6n5rckvJ+/LRcetya3IL6cXPbZ4FAlwqGLQACgkQa3IL6cXP bZ6dkRAAzlQFCGiJIYpKqNa5kzVcWjTpSzJTfUTxtnoKyAgl4O8WOihyjDn7lKKO xuFAunMTTpoWkUEsn4bN8209hm8sMmuM6wJDrdQnKV4llyReGKMuk8DNHz38u3cs e7dMi2VNAdn/vrOFEGeyPcVbonOfdoCoyXxJHnWmZBBcnSFFIEvo5hnXrKuou84m 0R6f9qLPpjd1xRKd3cl2dJxfTbDRCMbpxgbu5U4aEd4HlkgHklgmdpz/hR9dvU+8 7VsgfbxfW06e4DNk51rpggJbX7rukMIJMU9HHG/I7LdzgM5F/HXw98fja3w/CKyj h9vdHHvqPb6QxAQek7thOPVbP3ImkbVkiO0pkUhRrf5BcgjFBNfYq/1hAAI/70UE bcxh938EOOHE/VAhVN+0tcyE/G9DOo35hHe7/NhkM75eezZRCD4tXHMw4gdcJ6n5 6sHm5gJEtab6aX7BsKsZaEnZ9l/qEAJf5XwsHqMgMQYhpA9Z9Q+noT3gGaWV1QMD vGi3G/7TwLycEyzsdrsfdj6uIaVmIJrzl3GqJZFqfwlQJgRM5d8s00zwi3M+wUZU Mh34bUOVADrc5sLUWFtrQVW3oBZOC25edo5gJHvXQw72nld5xrgNGbLDKkDj94Sf Fd3dxGf/YrLpS3AJ8otVZDhs8R9BhOYXhIsnKKdAJSX9RrjCsgA= =rVTS -END PGP SIGNATURE-
Bug#917889: ITP: fuser-overlayfs -- An implementation of overlay+shiftfs in FUSE for rootless containers.
Packaging available at https://salsa.debian.org/debian/fuse-overlayfs This program is going to use fuse3, which is not co-installable with fuse2. cf. - http://lists.debian.org/ca+fnjvb3j4h81k+bcxm3d2zjgheenjxhws06c5avicr51jg...@mail.gmail.com - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912526 Advise, suggestions and co-maintainers more than welcome! -rt
Bug#917889: ITP: fuser-overlayfs -- An implementation of overlay+shiftfs in FUSE for rootless containers.
Packaging available at https://salsa.debian.org/debian/fuse-overlayfs This program is going to use fuse3, which is not co-installable with fuse2. cf. - http://lists.debian.org/ca+fnjvb3j4h81k+bcxm3d2zjgheenjxhws06c5avicr51jg...@mail.gmail.com - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912526 Advise, suggestions and co-maintainers more than welcome! -rt
Bug#917889: ITP: fuser-overlayfs -- An implementation of overlay+shiftfs in FUSE for rootless containers.
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: fuser-overlayfs Version : 0.2 Upstream Author : Giuseppe Scrivano 2001-2007 Miklos Szeredi * URL : https://github.com/containers/fuse-overlayfs * License : GPLv3 Programming Lang: C Description : An implementation of overlay+shiftfs in FUSE for rootless containers. fuse-overlayfs provides an overlayfs FUSE implementation so that it can be used since Linux 4.18 by unprivileged users in an user namespace.
Bug#917889: ITP: fuser-overlayfs -- An implementation of overlay+shiftfs in FUSE for rootless containers.
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: fuser-overlayfs Version : 0.2 Upstream Author : Giuseppe Scrivano 2001-2007 Miklos Szeredi * URL : https://github.com/containers/fuse-overlayfs * License : GPLv3 Programming Lang: C Description : An implementation of overlay+shiftfs in FUSE for rootless containers. fuse-overlayfs provides an overlayfs FUSE implementation so that it can be used since Linux 4.18 by unprivileged users in an user namespace.
Bug#917889: ITP: fuser-overlayfs -- An implementation of overlay+shiftfs in FUSE for rootless containers.
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: fuser-overlayfs Version : 0.2 Upstream Author : Giuseppe Scrivano 2001-2007 Miklos Szeredi * URL : https://github.com/containers/fuse-overlayfs * License : GPLv3 Programming Lang: C Description : An implementation of overlay+shiftfs in FUSE for rootless containers. fuse-overlayfs provides an overlayfs FUSE implementation so that it can be used since Linux 4.18 by unprivileged users in an user namespace.
Bug#917337: ITP: slirp4netns -- User-mode networking for unprivileged network namespaces
Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler
Package name: slirp4netns
Version : git HEAD
Upstream Author : Akihiro Suda
URL : https://github.com/rootless-containers/slirp4netns
License : GPLv2+
Programming Lang: C
Description : User-mode networking for unprivileged network namespaces
slirp4netns provides user-mode networking for unprivileged network
namespaces.
.
slirp4netns allows connecting a network namespace to the Internet in a
completely unprivileged way, by connecting a TAP device in a network
namespace to the usermode TCP/IP stack ("slirp").
This is a dependency of buildah and podman, which I am looking at for packaging
right now as well.
I'd appreciate suggestions for what team would be appropriate to maintain this
group of packages. Unless better suggestions come up, I intend to maintain it
on salsa.debian.org in the "Debian" group
(cf.
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group).
More information as taken from
https://github.com/rootless-containers/slirp4netns/blob/master/README.md:
Motivation
Starting with Linux 3.8, unprivileged users can create network_namespaces(7)
along with user_namespaces(7). However, unprivileged network namespaces had not
been very useful, because creating veth(4) pairs across the host and network
namespaces still requires the root privileges. (i.e. No internet connection)
slirp4netns allows connecting a network namespace to the Internet in a
completely unprivileged way, by connecting a TAP device in a network namespace
to the usermode TCP/IP stack ("slirp").
Projects using slirp4netns:
- Usernetes (via RootlessKit)
- Podman
- Buildah
- ctnr (via slirp-cni-plugin)
- RootlessKit
- become-root
- slirp-cni-plugin
Bug#917337: ITP: slirp4netns -- User-mode networking for unprivileged network namespaces
Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler
Package name: slirp4netns
Version : git HEAD
Upstream Author : Akihiro Suda
URL : https://github.com/rootless-containers/slirp4netns
License : GPLv2+
Programming Lang: C
Description : User-mode networking for unprivileged network namespaces
slirp4netns provides user-mode networking for unprivileged network
namespaces.
.
slirp4netns allows connecting a network namespace to the Internet in a
completely unprivileged way, by connecting a TAP device in a network
namespace to the usermode TCP/IP stack ("slirp").
This is a dependency of buildah and podman, which I am looking at for packaging
right now as well.
I'd appreciate suggestions for what team would be appropriate to maintain this
group of packages. Unless better suggestions come up, I intend to maintain it
on salsa.debian.org in the "Debian" group
(cf.
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group).
More information as taken from
https://github.com/rootless-containers/slirp4netns/blob/master/README.md:
Motivation
Starting with Linux 3.8, unprivileged users can create network_namespaces(7)
along with user_namespaces(7). However, unprivileged network namespaces had not
been very useful, because creating veth(4) pairs across the host and network
namespaces still requires the root privileges. (i.e. No internet connection)
slirp4netns allows connecting a network namespace to the Internet in a
completely unprivileged way, by connecting a TAP device in a network namespace
to the usermode TCP/IP stack ("slirp").
Projects using slirp4netns:
- Usernetes (via RootlessKit)
- Podman
- Buildah
- ctnr (via slirp-cni-plugin)
- RootlessKit
- become-root
- slirp-cni-plugin
Bug#917337: ITP: slirp4netns -- User-mode networking for unprivileged network namespaces
Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler
Package name: slirp4netns
Version : git HEAD
Upstream Author : Akihiro Suda
URL : https://github.com/rootless-containers/slirp4netns
License : GPLv2+
Programming Lang: C
Description : User-mode networking for unprivileged network namespaces
slirp4netns provides user-mode networking for unprivileged network
namespaces.
.
slirp4netns allows connecting a network namespace to the Internet in a
completely unprivileged way, by connecting a TAP device in a network
namespace to the usermode TCP/IP stack ("slirp").
This is a dependency of buildah and podman, which I am looking at for packaging
right now as well.
I'd appreciate suggestions for what team would be appropriate to maintain this
group of packages. Unless better suggestions come up, I intend to maintain it
on salsa.debian.org in the "Debian" group
(cf.
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group).
More information as taken from
https://github.com/rootless-containers/slirp4netns/blob/master/README.md:
Motivation
Starting with Linux 3.8, unprivileged users can create network_namespaces(7)
along with user_namespaces(7). However, unprivileged network namespaces had not
been very useful, because creating veth(4) pairs across the host and network
namespaces still requires the root privileges. (i.e. No internet connection)
slirp4netns allows connecting a network namespace to the Internet in a
completely unprivileged way, by connecting a TAP device in a network namespace
to the usermode TCP/IP stack ("slirp").
Projects using slirp4netns:
- Usernetes (via RootlessKit)
- Podman
- Buildah
- ctnr (via slirp-cni-plugin)
- RootlessKit
- become-root
- slirp-cni-plugin
Accepted aspectc++ 1:2.2+git20181008-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 23 Oct 2018 08:08:17 -0400 Source: aspectc++ Binary: aspectc++ libpuma-dev libpuma-doc Architecture: source Version: 1:2.2+git20181008-2 Distribution: unstable Urgency: medium Maintainer: Reinhard Tartler Changed-By: Reinhard Tartler Description: aspectc++ - aspect-oriented programming extension for C++ libpuma-dev - C/C++/AspectC++ Scanner and Parsers libpuma-doc - C/C++/AspectC++ Scanner and Parsers Changes: aspectc++ (1:2.2+git20181008-2) unstable; urgency=medium . * Avoid using __float128 types, fixes FTBFS on ppc64el Checksums-Sha1: 6e771f61f472ddce0fb97710eb6870f2755294b6 2315 aspectc++_2.2+git20181008-2.dsc e345c33799e9d1718bc3ea9efe1cf73b443619d5 15300 aspectc++_2.2+git20181008-2.debian.tar.xz Checksums-Sha256: 8d8a49d9e38d6271b804ff3f88a0c2e9ed5b03d77f3764055cb03cf610f37d6a 2315 aspectc++_2.2+git20181008-2.dsc a3a2b1f8e85c0331e87f29242ad32da53f8d3c06c9006081cfa3b53b4d215ebe 15300 aspectc++_2.2+git20181008-2.debian.tar.xz Files: fc4fc44621fe1f902f25806be01a421a 2315 devel optional aspectc++_2.2+git20181008-2.dsc 9c8c19cf369643a5b5eb81f279f4bdf7 15300 devel optional aspectc++_2.2+git20181008-2.debian.tar.xz -BEGIN PGP SIGNATURE- iQJIBAEBCAAyFiEE6n5rckvJ+/LRcetya3IL6cXPbZ4FAlvV9ggUHHNpcmV0YXJ0 QHRhdXdhcmUuZGUACgkQa3IL6cXPbZ4p3Q//WGbopJeAjD7VpSuLoMrl1Qy4el5I IDz0HPi5JEvYOev9O2jkhfL/3hRCxW1je+0E4CiUdbqGCSSYN63qkx8k6glyP20c 3gSV93pmi6BKDOyWC8+TPvbUurH4/YSJI2rUIJ70seqcXs3qHzyYHto1Zh+VEpLg hcvJH+Y/DyGVOlQon9/vb56QFNBzOud8lD0Cr41P4qe9+0BurSgABeJ3oFz19uyI w1Y6ojW5Abhk605FbQjIz/omFfz8KBprMrm0PfzrLz57TofQRog/OfJ5rcbMyhCU WeAGWHV511+OYvQrYUCHYPpsgx9aMAenGXcbijK/qMIhbh6GF+izeCUkRyPDU5p0 J1eOadERTTsJuP44j57ntsoQLQ2lNJoxOf5Q9dr9GA75N7HosXNCrUGrMXiZUjxy wtQsw+TLzBJVPwbF2mQ3LeE4GKEQdJzSViCR4BVSaxZrMqPEmGqGdLazdAI76vGZ Zu3egF60AHLpCZ1OXOVoq3I2NZ60dXwoO/CSik1/u6Z5yhM5B+agSUzn8ufj5L8O WEhhAL39U2BYzkvkCRJIseKM027lok0vM4p96T6qjAvj1DMiCVzbTOhrToWrffyw 5V+A0RwsIzrkGqCc65K+zd96qr0KkihgsC9q80a2J6+nJxL3vHMUXJREURh1GSsw ZGDBjN/h16xZv4w= =+Umc -END PGP SIGNATURE-
Accepted aspectc++ 1:2.2+git20181008-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 21 Oct 2018 10:05:31 -0400 Source: aspectc++ Binary: aspectc++ libpuma-dev libpuma-doc Architecture: source Version: 1:2.2+git20181008-1 Distribution: unstable Urgency: medium Maintainer: Reinhard Tartler Changed-By: Reinhard Tartler Description: aspectc++ - aspect-oriented programming extension for C++ libpuma-dev - C/C++/AspectC++ Scanner and Parsers libpuma-doc - C/C++/AspectC++ Scanner and Parsers Closes: 902220 Changes: aspectc++ (1:2.2+git20181008-1) unstable; urgency=medium . [ Ondřej Nový ] * d/changelog: Remove trailing whitespaces . [ Reinhard Tartler ] * New Upstream version. * Fix building with and build against Clang 6.0 with gcc-8. (Closes: #902220) Checksums-Sha1: 7ed4435f1a789c00046de88198dc09dc4af7e0b1 2315 aspectc++_2.2+git20181008-1.dsc 382ab46d7476b4bb621d7e6deb11296d27d0edc6 5270821 aspectc++_2.2+git20181008.orig.tar.gz 1765e4c1036e14bb24f5fe170ce7669ecb07cd9b 14900 aspectc++_2.2+git20181008-1.debian.tar.xz Checksums-Sha256: 21ba67ebcf7946c2614dd77145622e3ac52e729886713f8c16052a5e959b5137 2315 aspectc++_2.2+git20181008-1.dsc 089fc7ad0ec619179c25739621310ca87eeb63ec10833ba1a89aaae1a93ba876 5270821 aspectc++_2.2+git20181008.orig.tar.gz 3ca9117e27d0980e754a89c8516013e08ff4c427d2a31d8149dd4a08473e1f79 14900 aspectc++_2.2+git20181008-1.debian.tar.xz Files: bd76ee78ee3a37d2af61618849aafca9 2315 devel optional aspectc++_2.2+git20181008-1.dsc efdbbb1e500179b94a9ffc9392a68edc 5270821 devel optional aspectc++_2.2+git20181008.orig.tar.gz 2f933d2831dff92026119f9bc628da45 14900 devel optional aspectc++_2.2+git20181008-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQJIBAEBCAAyFiEE6n5rckvJ+/LRcetya3IL6cXPbZ4FAlvMroEUHHNpcmV0YXJ0 QHRhdXdhcmUuZGUACgkQa3IL6cXPbZ4nFA//bBnkEt8sHipxUDamHuYGnNy6diuw iUAfUHVLiR2sNVkB75+hG5JXNapjZYJ3POBllzDrKGeQ8hEep1gtRRadw5Oqsel8 Hy7YvcxcjVwXXKxbZHBpblnuyQ03axzZucADRBzOSRMTBPMfCz7mg9ycP+RGsVM0 /jltOaPgTOQPjer8bOH9fCeHWTFi3n/9XJhJNOHmlA1MYtF32d736NmitTGIAP3Z nt/rxcyu1J5Lx7AbB4acxvEGyIq9qTnDXCh23MkLhrHy1aOLeb8kq+tzFqQ63fvs PxY1e0otQFiU6Sz3g1hk/fXGMPIn0MQCfbdvf/VgQsx1pKnfZErPMDwt4PuL8x3I u38cbVK0B/udIYyUHnPbzaszkBqqVqijmKlRyFFl7T/tkU4m5mCXpBZz0Q0yf2+F pk/C4DxQm7h3BN7XXSH5+xv3Zv05IuPIB+xu9sFmqH2wDxxLGqWNbqz05eURHMdS pQDenUl2uxLE0qrclK7c87U/Mj0oZeblJ7ply1FE0vREe9Ygb5Gk1f+btmYgm3tT UFp6bJYXvYuYL2ZnfTtPPVSsHfOVB9riVPtkpfP6ovo556VzVAe3L/1fHc3tfh2A oUWCzUNGJLC4wHQhSz6a36DQpDWPngd5uGfPtPru6EPC4I2xL8ez1eRwLzhSpW/A arkv+p1zYKlYrj4= =iVsP -END PGP SIGNATURE-
Bug#903948: Dokuwiki: Link-Assistant in oldstable hangs
Control: found -1 0.0.20140505.a+dfsg-4+deb8u1 On 09/27/2018 01:28 AM, Matthias Faulstich wrote: > Dear Reinhard, > > the bug should be fixed in the repository > https://non-gnu.uvt.nl/ > as reported here > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903948 > > The fixed Package there is named as > dokuwiki_0.0.20140505.a+dfsg-4+deb8u2_all.deb > > But > http://http.debian.net/debian/ > still offers the old, buggy package, as you can see here: > > :~$ apt-cache show dokuwiki > Package: dokuwiki > Version: 0.0.20140505.a+dfsg-4+deb8u1 > ... > (executed this minute) You are correct that the bug still exists in the Debian "stable" distribution. The fix is now available in "unstable" and will be hopefully soon in "testing". See https://www.debian.org/releases/ for more information about stable releases. Please refer to our user mailing lists for user-level support: https://lists.debian.org/debian-user-german/ https://lists.debian.org/debian-user/ Best, Reinhard
Bug#857807: Proposed fix https://salsa.debian.org/debian/dokuwiki/merge_requests/1
Control: tag -1 patch Hi, I think the issue is that the file got dropped from the package, yet the default package is still referencing it. I took the liberty of taking the image from the jessie package and propose a change at https://salsa.debian.org/debian/dokuwiki/merge_requests/1. Tanguy, do you have any concerns or comments about this patch? -- regards, Reinhard
Bug#907632: [ppc64-el] Breaks building aspectc++
Package: gcc-8 Version: 8.2.0-4 Affects: aspectc++ X-Debbugs-CC: debian-powerpc@lists.debian.org Relevant part from https://buildd.debian.org/status/fetch.php?pkg=aspectc%2B%2B=ppc64el=1%3A2.2%2Bgit20170823-8=1535500793=0 In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/src/PrePrintVisitor.Icc:19: In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/PreSemIterator.h:24: In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/PreTreeIterator.h:24: In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/PreTree.h:26: In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/Token.h:26: In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/Location.h:25: In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/Filename.h:26: In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/Printable.h:25: In file included from /usr/include/c++/8/iostream:39: In file included from /usr/include/c++/8/ostream:38: In file included from /usr/include/c++/8/ios:38: In file included from /usr/include/c++/8/iosfwd:40: In file included from /usr/include/c++/8/bits/postypes.h:40: In file included from /usr/include/c++/8/cwchar:44: In file included from /usr/include/wchar.h:30: /usr/include/powerpc64le-linux-gnu/bits/floatn.h:72:52: error: unknown machine mode '__KC__' typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__KC__))); ^ /usr/include/powernpc64le-linux-gnu/bits/floatn.h:84:9: error: unknown type name '__ieee128' typedef __float128 _Float128; ^ :431:20: note: expanded from here #define __float128 __ieee128 ^ If you look at https://buildd.debian.org/status/logs.php?pkg=aspectc%2B%2B=ppc64el, you'll see that 1:2.2+git20170823-7 did build successfully. There are no relevant upstream code changes, but it was built with gcc-7, which works fine. 1:2.2+git20170823-8 uses gcc-8, and that breaks. Also it seems this bug seems to affect the architecture ppc64-el only. Any ideas, hints and suggestions are much appreciated. Best, -rt
Bug#907632: [ppc64-el] Breaks building aspectc++
Package: gcc-8 Version: 8.2.0-4 Affects: aspectc++ X-Debbugs-CC: debian-powe...@lists.debian.org Relevant part from https://buildd.debian.org/status/fetch.php?pkg=aspectc%2B%2B=ppc64el=1%3A2.2%2Bgit20170823-8=1535500793=0 In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/src/PrePrintVisitor.Icc:19: In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/PreSemIterator.h:24: In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/PreTreeIterator.h:24: In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/PreTree.h:26: In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/Token.h:26: In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/Location.h:25: In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/Filename.h:26: In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/Printable.h:25: In file included from /usr/include/c++/8/iostream:39: In file included from /usr/include/c++/8/ostream:38: In file included from /usr/include/c++/8/ios:38: In file included from /usr/include/c++/8/iosfwd:40: In file included from /usr/include/c++/8/bits/postypes.h:40: In file included from /usr/include/c++/8/cwchar:44: In file included from /usr/include/wchar.h:30: /usr/include/powerpc64le-linux-gnu/bits/floatn.h:72:52: error: unknown machine mode '__KC__' typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__KC__))); ^ /usr/include/powernpc64le-linux-gnu/bits/floatn.h:84:9: error: unknown type name '__ieee128' typedef __float128 _Float128; ^ :431:20: note: expanded from here #define __float128 __ieee128 ^ If you look at https://buildd.debian.org/status/logs.php?pkg=aspectc%2B%2B=ppc64el, you'll see that 1:2.2+git20170823-7 did build successfully. There are no relevant upstream code changes, but it was built with gcc-7, which works fine. 1:2.2+git20170823-8 uses gcc-8, and that breaks. Also it seems this bug seems to affect the architecture ppc64-el only. Any ideas, hints and suggestions are much appreciated. Best, -rt
Bug#907632: [ppc64-el] Breaks building aspectc++
Package: gcc-8 Version: 8.2.0-4 Affects: aspectc++ X-Debbugs-CC: debian-powe...@lists.debian.org Relevant part from https://buildd.debian.org/status/fetch.php?pkg=aspectc%2B%2B=ppc64el=1%3A2.2%2Bgit20170823-8=1535500793=0 In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/src/PrePrintVisitor.Icc:19: In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/PreSemIterator.h:24: In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/PreTreeIterator.h:24: In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/PreTree.h:26: In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/Token.h:26: In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/Location.h:25: In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/Filename.h:26: In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/Printable.h:25: In file included from /usr/include/c++/8/iostream:39: In file included from /usr/include/c++/8/ostream:38: In file included from /usr/include/c++/8/ios:38: In file included from /usr/include/c++/8/iosfwd:40: In file included from /usr/include/c++/8/bits/postypes.h:40: In file included from /usr/include/c++/8/cwchar:44: In file included from /usr/include/wchar.h:30: /usr/include/powerpc64le-linux-gnu/bits/floatn.h:72:52: error: unknown machine mode '__KC__' typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__KC__))); ^ /usr/include/powernpc64le-linux-gnu/bits/floatn.h:84:9: error: unknown type name '__ieee128' typedef __float128 _Float128; ^ :431:20: note: expanded from here #define __float128 __ieee128 ^ If you look at https://buildd.debian.org/status/logs.php?pkg=aspectc%2B%2B=ppc64el, you'll see that 1:2.2+git20170823-7 did build successfully. There are no relevant upstream code changes, but it was built with gcc-7, which works fine. 1:2.2+git20170823-8 uses gcc-8, and that breaks. Also it seems this bug seems to affect the architecture ppc64-el only. Any ideas, hints and suggestions are much appreciated. Best, -rt
Bug#890024: npapi-vlc: upcoming Firefox ESR dropping support for NPAPI
I agree that it's time to have the package npapi-vlc removed from unstable. Let's proceed with the RM bug.
Bug#890024: npapi-vlc: upcoming Firefox ESR dropping support for NPAPI
I agree that it's time to have the package npapi-vlc removed from unstable. Let's proceed with the RM bug.
Bug#890024: npapi-vlc: upcoming Firefox ESR dropping support for NPAPI
I agree that it's time to have the package npapi-vlc removed from unstable. Let's proceed with the RM bug. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#902220: Needs porting to LLVM 6.0.1
Control: retitle -1 Needs porting to LLVM 6.0.1 Well, I just checked, even the latest trunk does not support LLVM 6.0.1. Or rather, it builds (with some minor, obvious modifications), but doesn't work. I haven't tested LLVM 6.0.0, it may or may not work. This needs to be looked into more. -rt
Bug#902220: Needs porting to LLVM 6.0.1
Control: retitle -1 Needs porting to LLVM 6.0.1 Well, I just checked, even the latest trunk does not support LLVM 6.0.1. Or rather, it builds (with some minor, obvious modifications), but doesn't work. I haven't tested LLVM 6.0.0, it may or may not work. This needs to be looked into more. -rt
Bug#902220: Processed: reopening 902220
On 08/29/2018 08:24 AM, Adrian Bunk wrote: > AspectC++ upstream code already seems to support LLVM 6 (untested). That's contradictory to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906972#10 This needs to be looked into more. Also, why do you need to have this bug at severity serious? If llvm-4.0 was removed from testing, that would prevent packages such as aspectc++ from migrating as well? -rt
Bug#902220: Processed: reopening 902220
On 08/29/2018 08:24 AM, Adrian Bunk wrote: > AspectC++ upstream code already seems to support LLVM 6 (untested). That's contradictory to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906972#10 This needs to be looked into more. Also, why do you need to have this bug at severity serious? If llvm-4.0 was removed from testing, that would prevent packages such as aspectc++ from migrating as well? -rt
Bug#902220: Processed: reopening 902220
Control: severity -1 normal
Hi Adrian,
Thanks for your bug maintenance work, much appreciated!
On 08/28/2018 08:27 PM, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
>
>> reopen 902220
> Bug #902220 {Done: Reinhard Tartler } [aspectc++]
> aspect++: Please use llvm-dev instead of llvm-4.0-dev
Are you sure about the severity "serious" of this bug? AspectC++ still needs
porting to llvm-6.0 and won't build right now. llvm-4.0-dev is still in testing
at this point. Please provide a reference to the llvm upgrade timeline that I
could share with upstream.
Best,
-rt
Bug#902220: Processed: reopening 902220
Control: severity -1 normal
Hi Adrian,
Thanks for your bug maintenance work, much appreciated!
On 08/28/2018 08:27 PM, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
>
>> reopen 902220
> Bug #902220 {Done: Reinhard Tartler } [aspectc++]
> aspect++: Please use llvm-dev instead of llvm-4.0-dev
Are you sure about the severity "serious" of this bug? AspectC++ still needs
porting to llvm-6.0 and won't build right now. llvm-4.0-dev is still in testing
at this point. Please provide a reference to the llvm upgrade timeline that I
could share with upstream.
Best,
-rt
