Bug#924095: ITP: golang-github-containernetworking-cni -- Container Network Interface - networking for Linux containers
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: golang-github-containernetworking-cni Version : 0.6.0-1 Upstream Author : CNI * URL : https://github.com/containernetworking/cni * License : Apache-2.0 Programming Lang: Go Description : Container Network Interface - networking for Linux containers CNI consists of a specification and libraries for writing plugins to configure network interfaces in Linux containers, along with a number of supported plugins. CNI concerns itself only with network connectivity of containers and removing allocated resources when the container is deleted. Because of this focus, CNI has a wide range of support and the specification is simple to implement. This is a dependency of golang-github-containerd-go-cni signature.asc Description: PGP signature
Bug#924098: ITP: golang-github-containerd-go-cni -- generic CNI library to provide APIs for CNI plugin interactions
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: golang-github-containerd-go-cni Version : 0.0~git20190226.0683513-1 Upstream Author : containerd * URL : https://github.com/containerd/go-cni * License : Apache-2.0 Programming Lang: Go Description : generic CNI library to provide APIs for CNI plugin interactions The library provides APIs to: . * Load CNI network config from different sources * Setup networks for container namespace * Remove networks from container namespace * Query status of CNI network plugin initialization . go-cni aims to support plugins that implement Container Network Interface This is a dependency of containerd. signature.asc Description: PGP signature
Bug#924101: ITP: stringtie -- assemble short RNAseq reads to transcripts
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: stringtie * URL : http://ccb.jhu.edu/software/stringtie/ * License : Artistic-2.0 Description : assemble short RNAseq reads to transcripts To be team-maintained by Debian Med at https://salsa.debian.org/med-team/stringtie
Re: Debian Buster will only be 54% reproducible (while we could be at >90%)
On Tue, 5 Mar 2019 at 13:34, Holger Levsen wrote: > > hi, > > disclaimer: this has not yet been verified by anyone other than myself, > so I could very well be wrong. Reproducible builds are about enabling > anyone to independently verify that... ;p > > > == Reproducibility in theory == > > According to > https://tests.reproducible-builds.org/debian/buster/index_suite_amd64_stats.html > we have 26476 source packages (92.8%) which can be built reproducibly in > buster/amd64, out of 28523 source packages in total. > (These 28523 source packages build 57448 binary packages.) > > But these tests are done without looking at the actual .deb files distributed > from ftp.debian.org (and we always knew that and pointed it out: > "93% reproducible _in our current test framework_".) > So I guess after we release buster, we should do a mass-source-nmu no-change uploads to make the .deb reproducible as shipped in the archive. Is this thus then an effectively a maas bug-file request to sourcefully rebuild packages? -- Regards, Dimitri.
unsuscribe
Empty Message
