Bug#1064869: nmu: golang-github-cowsql-go-cowsql
Control: retitle -1 nmu: golang-github-cowsql-go-cowsql Control: affects -1 - src:cowsql I've backported a newer version of cowsql, which resolves the need for a binNMU of that package. A binNMU is still requested for golang-github-cowsql-go-cowsql in bookworm-backports. Mathias signature.asc Description: This is a digitally signed message part
Bug#1067369: fixed in cowsql 1.15.6-1
(Touching bug to reset AUTORM countdown.) signature.asc Description: This is a digitally signed message part
Bug#1069400: dqlite: FTBFS on arm64: dh_auto_test: error: make -j4 check "TESTSUITEFLAGS=-j4 --verbose" VERBOSE=1 returned exit code 2
Control: tags -1 + help unreproducible Control: severity -1 important Lowering bug severity to important since I can't reproduce this issue on any of my systems. Additionally, looking at the various reproducible builds shows the most recent arm64 build passed, while the amd64 one failed. Mathias signature.asc Description: This is a digitally signed message part
Bug#1069400: dqlite: FTBFS on arm64: dh_auto_test: error: make -j4 check "TESTSUITEFLAGS=-j4 --verbose" VERBOSE=1 returned exit code 2
Control: forwarded -1 https://github.com/canonical/dqlite/issues/643 Looks like a flaky test, and unrelated to the time_t transition. Mathias signature.asc Description: This is a digitally signed message part
Bug#1068101: RFS ping mini-httpd/1.30-10 -- Small HTTP server
Hi Alexandru, I haven't reviewed your package, however: On Sun, 2024-04-21 at 19:42 +0300, Alexandru Mihail wrote: > Thanks a lot and have a nice day, > Alexandru Mihail > mini-httpd maintainer It looks like you've been maintaining this package for a while now. Have you considered applying to become a Debian Maintainer[1]? That would allow you to eventually be given upload permissions on the mini- httpd package, so you wouldn't need to keep filing RFS bugs. :) Also, I suspect people might be more hesitant to sponsor packages after the actions of "Jia Tan" and the xz backdoor. Going through the process to become a DM can help demonstrate your commitment to good packaging and the Debian project as a whole. (I'm not in any way trying to suggest you might be a malicious actor, just that there's recently been [rightfully] a lot of scrutiny of how easy it can be for someone to mess with packages shipped by a distribution.) Mathias [1] -- https://nm.debian.org/public/newnm signature.asc Description: This is a digitally signed message part
Bug#1068136: Updating golang-github-golang-protobuf-1-5 to fix FTBFS
On Sat, 2024-04-20 at 22:40 +0800, Shengjing Zhu wrote: > On Sat, Apr 20, 2024 at 10:28 PM Mathias Gibbens wrote: > > > > Hi Anthony, > > > > A few weeks ago you uploaded a new version of golang-google-protobuf > > to unstable which caused a FTBFS in golang-github-golang-protobuf-1-5 > > v1.5.3 [1,2,3]. This has been blocking the transition of various golang > > packages from unstable to testing. > > > > I've verified that v1.5.4 of golang-github-golang-protobuf-1-5 builds > > fine on my amd64 system. `build-rdeps golang-github-golang-protobuf-1- > > 5-dev` identifies 219 rdeps in main, so I haven't kicked off a `ratt` > > run testing for any build regressions with the newer version yet. > > > > This is a known regression in 1.5.3, see > https://github.com/golang/protobuf/issues/1596#issuecomment-1981208282 Since that appears to be the only change in v1.5.4, would there be any concerns with uploading that version to unstable? This breakage is starting to cause FTBFS bugs to be filed against affected packages, such as hugo (#1069371). Mathias signature.asc Description: This is a digitally signed message part
Bug#1068136: Updating golang-github-golang-protobuf-1-5 to fix FTBFS
Hi Anthony, A few weeks ago you uploaded a new version of golang-google-protobuf to unstable which caused a FTBFS in golang-github-golang-protobuf-1-5 v1.5.3 [1,2,3]. This has been blocking the transition of various golang packages from unstable to testing. I've verified that v1.5.4 of golang-github-golang-protobuf-1-5 builds fine on my amd64 system. `build-rdeps golang-github-golang-protobuf-1- 5-dev` identifies 219 rdeps in main, so I haven't kicked off a `ratt` run testing for any build regressions with the newer version yet. Are you waiting on something specific before updating golang-github- golang-protobuf-1-5? Thanks, Mathias [1] -- https://qa.debian.org/excuses.php?package=golang-google-protobuf [2] -- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068136 [3] -- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069368 signature.asc Description: This is a digitally signed message part
Bug#1064852: fixed in incus 0.6-2
(Touching bug to reset AUTORM countdown.) signature.asc Description: This is a digitally signed message part
Bug#1063371: nmu: golang-github-tinylib-msgp
Control: retitle -1 nmu: golang-github-tinylib-msgp Control: affects -1 - src:golang-github-go-jose-go-jose I've backported a newer version of golang-github-go-jose-go-jose, which resolves the need for a binNMU of that package. A binNMU is still requested for golang-github-tinylib-msgp in bookworm-backports. Mathias signature.asc Description: This is a digitally signed message part
Bug#1067554: ITP: golang-github-ibm-sarama -- Client library for Apache Kafka
Package: wnpp Severity: wishlist Owner: Mathias Gibbens X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-ibm-sarama Version : 1.43.0-1 Upstream Author : IBM Corporation * URL : https://github.com/IBM/sarama * License : Expat Programming Lang: Go Description : Client library for Apache Kafka sarama is a pure Go client library for dealing with Apache Kafka (versions 0.8 and later). It includes a high-level API for easily producing and consuming messages, and a low-level API for controlling bytes on the wire when the high-level API is insufficient. This is a new dependency required to update golang-github-openzipkin- zipkin-go and will be team-maintained within the Go Packaging Team. signature.asc Description: This is a digitally signed message part
Bug#1067553: ITP: golang-github-eapache-go-resiliency -- Resiliency patterns for golang (library)
Package: wnpp Severity: wishlist Owner: Mathias Gibbens X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-eapache-go-resiliency Version : 1.6.0-1 Upstream Author : Evan Huus * URL : https://github.com/eapache/go-resiliency * License : Expat Programming Lang: Go Description : Resiliency patterns for golang (library) Resiliency patterns for golang. Based in part on Hystrix, Semian, and others. Currently implemented patterns include: . * circuit-breaker * semaphore * deadline/timeout * batching * retriable This is a new dependency required to update golang-github-openzipkin- zipkin-go and will be team-maintained within the Go Packaging Team. signature.asc Description: This is a digitally signed message part
Bug#1067552: ITP: golang-github-zitadel-schema -- Library to fill a struct with form values
Package: wnpp Severity: wishlist Owner: Mathias Gibbens X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-zitadel-schema Version : 1.3.0-1 Upstream Author : ZITADEL * URL : https://github.com/zitadel/schema * License : BSD-3-Clause Programming Lang: Go Description : Library to fill a struct with form values Package zitadel/schema converts structs to and from form values. This is a maintained fork of gorilla/schema. This is a new dependency required to update golang-github-zitadel-oidc and will be team-maintained within the Go Packaging Team. signature.asc Description: This is a digitally signed message part
Bug#1067551: ITP: golang-github-zitadel-logging -- Logging extension library
Package: wnpp Severity: wishlist Owner: Mathias Gibbens X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-zitadel-logging Version : 0.6.0-1 Upstream Author : ZITADEL * URL : https://github.com/zitadel/logging * License : Apache-2.0 Programming Lang: Go Description : Logging extension library Golang logging extension library used by other zitadel projects. This is a new dependency required to update golang-github-zitadel-oidc and will be team-maintained within the Go Packaging Team. signature.asc Description: This is a digitally signed message part
Bug#1064213: incus-agent: Incus Agent never starts due to ConditionPathExists
Control: tags -1 + help pending On Sun, 2024-02-18 at 19:48 +, stefa...@debian.org wrote: > It does that if incus-agent-setup is in the image. This was an image > without incus-agent-setup, just your incus-agent package. The incus-agent package does include incus-agent-setup, which is called from the service file's ExecStartPre stanza. I have synced up the packaged service file and setup script from the current Incus release. It looks like some refactoring was done to move from a systemd-triggered service to a udev rule-triggered start. Hopefully that will resolve the issue you've been seeing. > If the intention isn't to use the incus-agent package inside VMs, this > should be declared more clearly. It was my intention that the incus-agent package should be usable inside VMs. I appreciate the report that it wasn't. > Use a bare image without incus-agent-setup to reproduce the bug. I have been unable to reproduce this myself. I've tried to do so a variety of ways, but I'm guessing with my hardware/setup I'm just not triggering the race condition in the same way. I've pushed commit a15849186e1c1945985f5bfd872ba4ce98eb3461 with the incus-agent changes. It will be included with the Incus 0.7 upload, hopefully sometime Monday. When the new version is available, I'd appreciate if you could test to see if the changes in packaging for 0.7 resolve your issue. Mathias signature.asc Description: This is a digitally signed message part
Bug#1067041: Please also include "Incus UI"
Control: block 1067041 by 1067132 On Tue, 2024-03-19 at 15:47 +0900, Osamu Aoki wrote: > I realize that the current Debian package doesn't seem to set INCUS_UI. > > Do you plan to set it to `/var/lib/incus/ui`? I think that is better place to > put web page for distribution if it ever happens. For right now, I don't think I want to set a default INCUS_UI environment variable, as there isn't any corresponding packaging in Debian that would populate such a path. Better to let individuals set it themselves if they wish to manually make a web-based UI available. But I'd be happy to add that default along with a Recommends or Suggests when Incus UI is packaged and ready for upload into the archive. > I think someone with interest and good skill on typescript and node needs to > work on this to make real debian package. I'm blocking this bug by the RFP; thanks for filing it. Down the road if/when someone does the packaging work, please let me know of any progress that's made. Mathias signature.asc Description: This is a digitally signed message part
Bug#1067041: Please also include "Incus UI"
Hi Osamu, Prior to the LXD/Incus hard fork, I did have an ITP to look at packaging lxd-ui (#1036926). I think the "proper" way to package Incus UI would be to have it as a new package (incus-ui), which incus packaging could then Recommend or Suggest. I would also be more comfortable with Incus UI it was a proper fork of Canonical's repository that carried the seven patches from zabbly/incus. As a packager, we shouldn't be taking one upstream and totally transforming it into something else via patches since that's just too much work to carry in our packaging. :) My suggestion would be to rework this bug into a RFP and/or merge with the prior ITP. I don't have any plans to work on this, but someone else might. Mathias signature.asc Description: This is a digitally signed message part
Bug#988730: CVE-2017-18641
On Sun, 2024-01-28 at 08:44 +0100, Salvatore Bonaccorso wrote: > Thanks for the update. Do you know of any plans of making > distrobuilder available? distrobuilder is now available in both testing and unstable. I'll be reaching out to some of the users of lxc-templates to let them know and suggesting that they migrate to using distrobuilder. Mathias signature.asc Description: This is a digitally signed message part
Bug#1064852: incus: missing depends on iproute2
On Tue, 2024-03-05 at 14:19 +0100, Helmut Grohne wrote: > debvm-create --include=incus > # This should have created a file named rootfs.ext4. > debvm-run Thanks for sharing that! > Rather than adding debvm on top of your testing, I think adding > autopkgtests with isolation-machine should get you more automatic > coverage. Possibly such tests need to be explicitly allowed by debci > folks and currently are only available on amd64. Yes, it would be nice to get better autopkgtest coverage for incus, lxc, and lxcfs. I'll add it to my todo list for these packages. :) Mathias signature.asc Description: This is a digitally signed message part
Bug#1064852: incus: missing depends on iproute2
Control: tags -1 + pending It's easy enough to add iproute2 as a dependency, so I've done so. Incus already has quite a number of dependencies, and I'd like to keep that list as small as possible, which is why I was initially reluctant to add iproute2. I would be interested to know more about what environment Incus is being used in that doesn't have the `ip` command available. My normal testing setup for Incus is a fresh, minimal expert install of sid via the netinst iso. During the install of the VM, I only install the base system and deselect the "standard system utilities" group. I do use DHCP, which looks like that might be responsible for pulling in iproute2 for me. If there's a way to create an even more minimal install, I'd be happy to incorporate that into my testing routine. Mathias signature.asc Description: This is a digitally signed message part
Bug#1065174: incus: VM agent isn't injected if /etc/environment sets PATH
Control: tags -1 + confirmed pending Thanks for the report -- I've moved setting $PATH from the service files to /etc/default/incus which is then read in via another EnvironmentFile statement. https://salsa.debian.org/go-team/packages/incus/-/commit/33e55353824a7bb0781f362ae3babb8932d84fef Mathias signature.asc Description: This is a digitally signed message part
Bug#1065009: ITP: golang-github-muhlemmer-httpforwarded -- Library for parsing the HTTP Forwarded header (RFC-7239)
Package: wnpp Severity: wishlist Owner: Mathias Gibbens X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-muhlemmer-httpforwarded Version : 0.1.0-1 Upstream Author : Tim Möhlmann * URL : https://github.com/muhlemmer/httpforwarded * License : BSD-3-clause Programming Lang: Go Description : Library for parsing the HTTP Forwarded header (RFC-7239) The httpforwarded go package provides utility functions for working with the Forwarded HTTP header as defined in RFC-7239 (https://tools.ietf.org/html/rfc7239). This header is proposed to replace the X-Forwarded-For and X-Forwarded-Proto headers, amongst others. . This package was heavily inspired by the mime package in the standard library, more specifically the ParseMediaType() function. This is a new dependency required to update golang-github-zitadel-oidc and will be team-maintained within the Go Packaging Team. signature.asc Description: This is a digitally signed message part
Bug#1064852: incus: missing depends on iproute2
Control: tags -1 + moreinfo Hi Helmut, iproute2 is Priority: important, which according to Policy §2.5 means that it is generally expected to be present on a Debian system. Do you have a specific use case where for some reason you don't have iproute2 installed? I'm initially reluctant to explicitly list iproute2 as a dependency for Incus unless there's some very compelling reason. Mathias signature.asc Description: This is a digitally signed message part
Bug#1064869: nmu: cowsql, golang-github-cowsql-go-cowsql
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Tags: bookworm-backports Control: affects -1 + src:cowsql Control: affects -1 + src:golang-github-cowsql-go-cowsql nmu cowsql_1.15.4-1~bpo12+1 . amd64 . bookworm-backports . -m "Build on buildd" nmu golang-github-cowsql-go-cowsql_1.22.0-2~bpo12+1 . amd64 . bookworm-backports . -m "Build on buildd" I would like for the amd64 builds to happen on official buildds, rather than relying on my amd64 upload as part of processing through BACKPORTS-NEW. I'm not sure when the next update in unstable to either package will be, so I'd like to schedule a binNMU. Thanks, Mathias signature.asc Description: This is a digitally signed message part
Bug#1064213: incus-agent: Incus Agent never starts due to ConditionPathExists
Control: severity -1 normal Hi Stefano, I suspect you're seeing this on the host system running Incus? If so, that's expected behavior. Incus' default mode of operation when launching a VM is to dynamically inject the `incus-agent` binary into the VM's environment. (`incus-agent` should never actually run on the host itself.) To accomplish this, it must copy the binary from the host system in addition to automatically creating other config and service files for the VM. Debian's packaging breaks out the `incus-agent` binary into its own package that is Recommended, but not required if you're only running containers. This setup covers the vast majority of regular Incus use. But, because there is an incus-agent package we also need to support someone creating a VM image that bakes in that package. Thus, there's a service definition in the incus-agent package. The ConditionPathExists check should ever only be true within a VM running under Incus. I've just verified that both use cases appear to work properly, so I've downgraded the bug's severity to normal. If you know of a better way of making the systemd service not start on the host machine, please let me know. Or if there might be some way to make it more readily apparent that it's expected and normal behavior. Mathias signature.asc Description: This is a digitally signed message part
Bug#1063925: victoriametrics: Occasional FTBFS: VictoriaMetrics/lib/storage/inmemory_part.go:37 BUG: Inmemory.InitFromRows must accept at least one row
Hi Denys, On Thu, 2024-02-15 at 08:22 +0200, Denys Holius wrote: > This version is an old and not supported version deprecated six month ago. > I belive this bug has been fixed in the newest versions of VictoriaMetrics. > Please see https://victoriametrics.com/blog/lts-status-h2-2023/ to find > the actual list of supported versions. Yes, the version in Debian unstable is currently out of date. Typically it's up to the interested party(ies) to update packages -- in this case, it looks like Guillem Jover. Eventually a newer version will be uploaded. Mathias signature.asc Description: This is a digitally signed message part
Bug#1063925: victoriametrics: Occasional FTBFS: VictoriaMetrics/lib/storage/inmemory_part.go:37 BUG: Inmemory.InitFromRows must accept at least one row
Source: victoriametrics
Version: 1.79.14+ds1-1
Severity: normal
Tags: trixie sid ftbfs
In a clean sid schroot, I observed an occasional test failure (2/9
builds):
> 2024-02-14T22:25:03.764Zpanic
> VictoriaMetrics/lib/storage/inmemory_part.go:37 BUG: Inmemory.InitFromRows
> must accept at least one row
> --- FAIL: TestMergeBlockStreamsManyStreamsManyBlocksManyRows (0.00s)
> panic: BUG: Inmemory.InitFromRows must accept at least one row [recovered]
> panic: BUG: Inmemory.InitFromRows must accept at least one row
>
> goroutine 56566 [running]:
> testing.tRunner.func1.2({0x6e5360, 0xc005603000})
> /usr/lib/go-1.21/src/testing/testing.go:1545 +0x238
> testing.tRunner.func1()
> /usr/lib/go-1.21/src/testing/testing.go:1548 +0x397
> panic({0x6e5360?, 0xc005603000?})
> /usr/lib/go-1.21/src/runtime/panic.go:914 +0x21f
> github.com/VictoriaMetrics/VictoriaMetrics/lib/logger.logMessage({0x72f3fd,
> 0x5}, {0xc0058a0e80, 0x37}, 0x0?)
>
> /build/victoriametrics-1.79.14+ds1/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/logger/logger.go:269
> +0x95e
> github.com/VictoriaMetrics/VictoriaMetrics/lib/logger.logLevelSkipframes(0x1,
> {0x72f3fd, 0x5}, {0x747753?, 0xc0017bee30?}, {0x0?, 0x90?, 0x7166e0?})
>
> /build/victoriametrics-1.79.14+ds1/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/logger/logger.go:137
> +0x194
> github.com/VictoriaMetrics/VictoriaMetrics/lib/logger.logLevel(...)
>
> /build/victoriametrics-1.79.14+ds1/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/logger/logger.go:129
> github.com/VictoriaMetrics/VictoriaMetrics/lib/logger.Panicf(...)
>
> /build/victoriametrics-1.79.14+ds1/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/logger/logger.go:125
> github.com/VictoriaMetrics/VictoriaMetrics/lib/storage.(*inmemoryPart).InitFromRows(0xc0036eb200,
> {0x0, 0x0, 0x0})
>
> /build/victoriametrics-1.79.14+ds1/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/storage/inmemory_part.go:37
> +0x58
> github.com/VictoriaMetrics/VictoriaMetrics/lib/storage.newTestBlockStreamReader(0xc001934878?,
> {0x0, 0x0, 0x0})
>
> /build/victoriametrics-1.79.14+ds1/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/storage/block_stream_reader_test.go:151
> +0x45
> github.com/VictoriaMetrics/VictoriaMetrics/lib/storage.TestMergeBlockStreamsManyStreamsManyBlocksManyRows(0x60a440?)
>
> /build/victoriametrics-1.79.14+ds1/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/storage/merge_test.go:325
> +0x11b
> testing.tRunner(0xc001811860, 0x7cc288)
> /usr/lib/go-1.21/src/testing/testing.go:1595 +0xff
> created by testing.(*T).Run in goroutine 1
> /usr/lib/go-1.21/src/testing/testing.go:1648 +0x3ad
> FAILgithub.com/VictoriaMetrics/VictoriaMetrics/lib/storage 12.339s
signature.asc
Description: This is a digitally signed message part
Bug#1063822: ITP: lxc-ci -- Official image definitions for distrobuilder
Package: wnpp Severity: wishlist Owner: Mathias Gibbens X-Debbugs-CC: debian-de...@lists.debian.org, pkg-lxc-de...@lists.alioth.debian.org * Package name: lxc-ci Version : 0.0~git20240210.e5f93e4-1 Upstream Author : Linux Containers Project * URL : https://github.com/lxc/lxc-ci * License : Apache-2.0 Programming Lang: yaml Description : Official image definitions for distrobuilder This package contains the official yaml definitions used by the Linux Containers Project to generate the pre-built images offered at https://images.linuxcontainers.org/. This will be kind of a weird package -- the source is lxc-ci, which contains all the bits and pieces to run the Linux Containers Project's Jenkins server. However, Debian will only be interested in the image yaml files for use with the distrobuilder package, so the produced binary package is distrobuilder-images. It will be team-maintained with the pkg-lxc team. signature.asc Description: This is a digitally signed message part
Bug#1063746: golang-github-katalix-go-l2tp: FTBFS: transport_test.go:388: test sender function reported an error: failed to send Hello message: transmit of avpMsgTypeHello failed after 3 retry attempt
Source: golang-github-katalix-go-l2tp Version: 0.1.6-2 Severity: serious Justification: FTBFS Tags: trixie sid ftbfs In a clean sid schroot, one of the tests is timing out: > transport_test.go:388: test sender function reported an error: failed to > send Hello message: transmit of avpMsgTypeHello failed after 3 retry attempts > panic: test timed out after 10m0s > running tests: > TestBasicSendReceive (9m59s) > TestBasicSendReceive/5:_send/recv_[::1]:9000_[::1]:9001_L2TPv3_IP > (9m59s) > > [snip goroutine tracebacks] This is also occurring in the debci runs: https://ci.debian.net/packages/g/golang-github-katalix-go-l2tp/ signature.asc Description: This is a digitally signed message part
Bug#831850: lxc: Please add a way to set root password for debian template
Control: tags -1 + wontfix Given that we've now had four releases of Debian without the capability to set a root password via template argument and that the upstream project is depreciated, I don't think it's worth the effort to add this capability back -- tagging with wontfix. It's still documented in lxc's README.Debian that you can run `lxc-attach -n passwd` to set a root password if really needed. Mathias signature.asc Description: This is a digitally signed message part
Bug#1061706: ITP: distrobuilder -- System container image builder for LXC and Incus
Will likely want to package the lxc-ci image yamls from https://github.com/lxc/lxc-ci as "distrobuilder-images" and depend on that to provide a good set of image templates. signature.asc Description: This is a digitally signed message part
Bug#992255: openvpn fails in a container (missing cgroup2 support)
It seems reasonable to me to add corresponding "lxc.cgroup2.devices.allow" lines to the debian configuration file. That appears to be the common solution that other users of lxc have done when searching for discussions of similar issues. I'm not going to immediately push the updated config, as I don't want to accidentally break something or weaken an assumed protection that currently exists. However, if I don't hear any objections after a while I'll make the changes later this year. Mathias signature.asc Description: This is a digitally signed message part
Bug#1008196: lxc-templates: Permission issues on device nodes: move to cgroups2
Control: merge 992255 1008196 This is the same issue as reported in bug #992255. Mathias signature.asc Description: This is a digitally signed message part
Bug#907615: lxc-console not getting prompt with debian template
Control: tags -1 + confirmed Control: found -1 lxc-templates/3.0.4.48.g4765da8-1 I've confirmed that this issue is still present in bookworm, and that adding "-t 0" to `lxc-console` does allow one to properly connect to the container's console. Mathias signature.asc Description: This is a digitally signed message part
Bug#1055370: consider adding security repos by default
Control: tags -1 + moreinfo lxc already appears to be setting the security repo by default for containers created with the debian template. On a bookworm system, creating both a bookworm and bullseye container results in a sources.list file that looks like this (of course, bullseye had the proper release name): > deb http://deb.debian.org/debian bookworm main > deb http://security.debian.org/debian-security bookworm-security main I suspect debci is either adding options or directly generating a sources.list that is injected into the container. The word "debug" doesn't appear anywhere within the debian template script and I'm not sure how the "deb-src" lines could be introduced with the existing template logic. Maybe there's something else going on in lxc-templates, but I'm not seeing anything immediately obvious to explain where debci's sources.list is coming from. Mathias signature.asc Description: This is a digitally signed message part
Bug#1036640: debian template's help lists archived releases that are not installable
Control: tags -1 + pending Hi Santiago, Thanks for the report. With the latest version of lxc-templates (pending upload with some related bug fixes) it is possible to create containers for jessie and stretch; wheezy and earlier simply no longer work: > lxc-create -t debian -n stretch -- -r stretch \ > --mirror=http://archive.debian.org/debian \ > --keyring=/usr/share/keyrings/debian-archive-removed-keys.gpg The jessie container starts up, but it doesn't automatically get an IP -- I didn't perform any further investigation. stretch works just fine. I have updated the list of supported releases in the template's help output to list only non-archived releases. Underlying support is still there, and a new section in the help output will describe how to create a container for an archived release. Mathias signature.asc Description: This is a digitally signed message part
Bug#1063371: nmu: golang-github-go-jose-go-jose, golang-github-tinylib-msgp
Control: tags -1 bookworm-backports signature.asc Description: This is a digitally signed message part
Bug#1063371: nmu: golang-github-go-jose-go-jose, golang-github-tinylib-msgp
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Tags: bookworm-backports Control: affects -1 + src:golang-github-go-jose-go-jose Control: affects -1 + src:golang-github-tinylib-msgp nmu golang-github-go-jose-go-jose_3.0.1-2~bpo12+1 . amd64 . bookworm-backports . -m "Build on buildd" nmu golang-github-tinylib-msgp_1.1.9-1~bpo12+1 . amd64 . bookworm-backports . -m "Build on buildd" I would like for the amd64 builds to happen on official buildds, rather than relying on my amd64 upload as part of processing through BACKPORTS-NEW. I'm not sure when the next update in unstable to either package will be, so I'd like to schedule a binNMU. Thanks, Mathias signature.asc Description: This is a digitally signed message part
Bug#1063036: ITP: golang-github-casbin-govaluate -- Arbitrary expression evaluation for golang
Package: wnpp Severity: wishlist Owner: Mathias Gibbens X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-casbin-govaluate Version : 1.1.1-1 Upstream Author : Casbin * URL : https://github.com/casbin/govaluate * License : Expat Programming Lang: Go Description : Arbitrary expression evaluation for golang Provides support for evaluating arbitrary C-like artithmetic/string expressions. . Sometimes, you can't know ahead-of-time what an expression will look like, or you want those expressions to be configurable. Perhaps you've got a set of data running through your application, and you want to allow your users to specify some validations to run on it before committing it to a database. Or maybe you've written a monitoring framework which is capable of gathering a bunch of metrics, when evaluating a few expressions to see if any metrics should be alerted upon, but the conditions for alerting are different for each monitor. . A lot of people wind up writing their own half-baked style of evaluation language that fits their needs, but isn't complete. Or they wind up baking the expression into the actual executable, even if they know it's subject to change. These strategies may work, but they take time to implement, time for users to learn, and induce technical debt as requirements change. This library is meant to cover all the normal C-like expressions, so that you don't have to reinvent one of the oldest wheels on a computer. . This is a fork of github.com/Knetic/govaluate, maintained by Casbin. This package is a new dependency for updating golang-github-casbin- casbin-dev, and will be team-maintained within the Go Packaging Team. signature.asc Description: This is a digitally signed message part
Bug#1062770: raft: NMU diff for 64-bit time_t transition
Hi Sergio, raft 0.21.0-1 was uploaded to unstable yesterday. Could you rebase on top of that release for the time_t transition? Until the transition is complete, we'll refrain from making further uploads to unstable. Free, I'll make a debian/experimental branch in salsa to track the NMU changes. Mathias signature.asc Description: This is a digitally signed message part
Bug#1062679: lxc: NMU diff for 64-bit time_t transition
ACK -- I won't plan to make any uploads of src:lxc to unstable until after the time_t transition is complete. For the team, I've applied the NMU to the debian/experimental branch up in salsa. Mathias signature.asc Description: This is a digitally signed message part
Bug#1061706: ITP: distrobuilder -- System container image builder for LXC and Incus
On Mon, 2024-01-29 at 08:02 +0100, Johannes Schauer Marin Rodrigues wrote: > independent on whether this is packaged or not, could you complete the entry > for distrobuilder in this table? > > https://wiki.debian.org/SystemBuildTools#General_tools Sure, done! Mathias signature.asc Description: This is a digitally signed message part
Bug#960169: lxc-templates: Fails to install when /var/lib/lxc is a symlink
Control: tags -1 + pending On Sun, 10 May 2020 08:04:03 +0200 ibu wrote: > If the empty dir var/lib/lxc (and maybe var/cache/lxc, too) is not > needed otherwise, I suggest removing it. I noticed those empty directories as well, which I think are leftover from when lxc-templates was split out from lxc. I've removed their creation during build, which will be included in the next upload of this package. Mathias signature.asc Description: This is a digitally signed message part
Bug#1061709: golang-github-heroku-docker-registry-client -- Client for the v2 Docker Registry API
Control: retitle -1 ITP: golang-github-heroku-docker-registry-client -- Client for the v2 Docker Registry API signature.asc Description: This is a digitally signed message part
Bug#1061709: golang-github-heroku-docker-registry-client -- Client for the v2 Docker Registry API
Package: wnpp Severity: wishlist Owner: Mathias Gibbens X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-heroku-docker-registry-client Version : 0.0~git20211012.9463674-1 Upstream Author : Heroku * URL : https://github.com/heroku/docker-registry-client * License : BSD-3-clause Programming Lang: Go Description : Client for the v2 Docker Registry API An API client for the V2 Docker Registry API, for Go applications. This is a dependency for packaging distrobuilder, and will be team- maintained within the Go Packaging Team. signature.asc Description: This is a digitally signed message part
Bug#1061707: ITP: golang-github-antchfx-htmlquery -- XPath package for HTML query
Package: wnpp Severity: wishlist Owner: Mathias Gibbens X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-antchfx-htmlquery Version : 1.3.0-1 Upstream Author : antchfx * URL : https://github.com/antchfx/htmlquery * License : Expat Programming Lang: Go Description : XPath package for HTML query htmlquery is an XPath query package for HTML, letting you extract data or evaluate from HTML documents by an XPath expression. This is a dependency for packaging distrobuilder, and will be team- maintained within the Go Packaging Team. signature.asc Description: This is a digitally signed message part
Bug#1061708: ITP: golang-github-mudler-docker-companion -- squash and unpack Docker images
Package: wnpp Severity: wishlist Owner: Mathias Gibbens X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-mudler-docker-companion Version : 0.4.5-1 Upstream Author : Ettore Di Giacinto * URL : https://github.com/mudler/docker-companion * License : GPLv3 Programming Lang: Go Description : squash and unpack Docker images docker-companion is a candy mix of tools for docker written in Golang and directly using Docker API calls. As for now it allows to squash and unpack an image. This is a dependency for packaging distrobuilder, and will be team- maintained within the Go Packaging Team. signature.asc Description: This is a digitally signed message part
Bug#1061706: ITP: distrobuilder -- System container image builder for LXC and Incus
Package: wnpp Severity: wishlist Owner: Mathias Gibbens X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: distrobuilder Version : 3.0-1 Upstream Author : Linux Containers Project * URL : https://github.com/lxc/distrobuilder * License : Apache-2.0 Programming Lang: Go Description : System container image builder for LXC and Incus distrobuilder is an image building tool for LXC and Incus. . Its modern design uses pre-built official images whenever available and supports a variety of modifications on the base image. distrobuilder creates LXC or Incus images, or just a plain root file system, from a declarative image definition (in YAML format) that defines the source of the image, its package manager, what packages to install or remove for specific image variants, OS releases and architectures, as well as additional files to generate and arbitrary actions to execute as part of the image build process. . Incus images may also be compatible with Canonical's LXD. distrobuilder has been the preferred way to create lxc/LXD/Incus images for several years now, replacing the legacy lxc-templates, but hasn't yet been packaged for Debian. This package will be team- maintained within the Go Packaging Team. signature.asc Description: This is a digitally signed message part
Bug#988730: CVE-2017-18641
On Sun, 2024-01-28 at 08:44 +0100, Salvatore Bonaccorso wrote: > Thanks for the update. Do you know of any plans of making > distrobuilder available? Up to this point I don't know of anything concrete. There are a few references over the years of people's desire to package it, but nothing much more appears to have happened. I will file an ITP shortly for distrobuilder, so it's at least on my radar to work on at some point in the future. Mathias signature.asc Description: This is a digitally signed message part
Bug#988730: CVE-2017-18641
Control: tags -1 + wontfix lxc-templates is essentially deprecated upstream in favor of distrobuilder. From the launchpad discussion: On 2020-02-05, Stéphane Graber wrote: > Back in LXC 3.0 we moved the legacy template scripts to their own > repository at https://github.com/lxc/lxc-templates and they are now > community maintained without security/lts commitments on them on our > side. Ubuntu still ships lxc-templates but it does so in universe > rather than main, matching the upstream commitment. And there was a discussion in debian-lts[1] about marking this CVE as no-dsa or ignored, which is how things are flagged in the security tacker. Given the amount of work required for very little gain and an inactive upstream, I'm tagging this bug as wontfix. Mathias [1] -- https://lists.debian.org/debian-lts/2020/02/msg00102.html signature.asc Description: This is a digitally signed message part
Bug#998095: lxc-templates: lxc-create using alpine template fails with mknod error
Control: tags -1 + pending Thanks for the report! I've verified the issue, and it will be fixed in the next upload of lxc-templates. Mathias signature.asc Description: This is a digitally signed message part
Bug#1055869: lxc-templates: need upgrade from upstream for templates issue
Control: tags -1 + pending Thanks for the reports! I'm working on packaging the latest snapshot of lxc-templates, which will fix both issues. Mathias signature.asc Description: This is a digitally signed message part
Bug#1061490: lxc: install PAM module into /usr
Control: tags -1 + pending Hi Michael, On Thu, 2024-01-25 at 14:41 +0100, Michael Biebl wrote: > We want to finalize the /usr-merge via DEP17 by moving all files to > /usr. lxc installs files into /lib; these should be moved into the > respective canonical locations in /usr/. > > Please find a patch attached. It has been build-tested. Thanks for the patch -- I've applied it, and it will be included in the next upload of lxc. > Note: this should not be backported to bookworm. If you intend to > backport, please use dh_movetousr instead. I don't anticipate lxc being backported to bookworm, so this shouldn't be an issue. > If your package will change for the t64 transition or otherwise > rename/split/move its binaries (packages) during trixie, please > then upload to experimental and get in touch with the UsrMerge > driver, please see the wiki [1]. I've added a personal note to watch for any sort of restructuring of lxc's packages during the rest of the trixie development cycle. If that is needed, we'll first do an upload to experimental before uploading to unstable. Mathias signature.asc Description: This is a digitally signed message part
Bug#1060614: lxc: Please switch Build-Depends to systemd-dev
Control: tags -1 + pending I've made this change, and it will be included in the next upload of lxc. Mathias signature.asc Description: This is a digitally signed message part
Bug#1060542: lxcfs: Please switch Build-Depends to systemd-dev
Control: tags -1 + pending I've made this change, and it will be included in the next upload of lxcfs. Mathias signature.asc Description: This is a digitally signed message part
Bug#1061299: RM: golang-github-duo-labs-webauthn -- ROM; deprecated upstream
Package: ftp.debian.org Severity: normal Please remove golang-github-duo-labs-webauthn. It has been deprecated upstream and replaced by golang-github-go-webauthn-webauthn, which was recently packaged for Debian. I updated the single rdep in main to switch to the new library, so there are no packages depending on golang-github-duo-labs-webauthn any more. Thanks, Mathias signature.asc Description: This is a digitally signed message part
Bug#1058592: LXD licensing changes and future for Debian packaging
Earlier today I uploaded what I expect to be the last significant packaging work for LXD that I will perform. The snapshot version of LXD appears to work correctly in sid, and I only anticipate making small tweaks if needed in advance of the trixie release next year. Referring to my email on 2023-12-13, steps 1-3 are now complete. Incus is available in testing & sid, and has feature parity with the version of LXD in Debian. Barring work by another motivated individual, the current plan is to ship the snapshot version of LXD in trixie while encouraging people to migrate to Incus sometime during trixie's lifetime. Once sid opens up following the trixie release, if there haven't been any significant changes, I plan to either modify src:lxd to only produce bin:golang- github-canonical-lxd-dev if Incus still depends on it to build the `lxd-to-incus` binary, or file a RM bug to totally remove LXD in forky. Mathias signature.asc Description: This is a digitally signed message part
Bug#1025857: Deprecated; replaced by github.com/go-webauthn/webauthn
Control: tags -1 + pending golang-github-go-webauthn-webauthn is now packaged, and I have updated golang-github-canonical-candid to use the new library. Currently there are no other rdeps on this library, so once candid migrates to testing, I'll file the RM bug. Mathias signature.asc Description: This is a digitally signed message part
Bug#1061158: ITP: discord-rpc -- library for Discord Rich Presence integration
Hi David, I would be willing to review and sponsor this package when it's ready. Feel free to ping me directly (no need to open a RFS bug.) openrct2 can use this library for Discord integration, but that is currently disabled in the Debian builds. I haven't tried to package this library because I'm not really a Discord user, and the library itself is deprecated in favor of Discord's GameSDK. However, as there are now two concrete cases where this would be useful in Debian (Citra and openrct2), if you're willing to do the work, I will help by sponsoring the upload. Mathias signature.asc Description: This is a digitally signed message part
Bug#1001989: RFP: golang-github-grafana-dskit -- Distributed systems kit
Control: retitle -1 RFP: golang-github-grafana-dskit -- Distributed systems kit Control: noowner -1 This library is no longer required to build Incus, so I no longer have a need to work on packaging it. So, converting to a RFP for anyone else to pickup in the future. I have pushed my current packaging work to salsa: https://salsa.debian.org/go-team/packages/golang-github-grafana-dskit/. Some notes of further work required as of today: * Depends on golang-github-go-redis-redis-dev (>= 8.11.5) * Might depend on golang-github-sercand-kuberesolver-dev (>= 5.1.1) * Depends on golang-github-hashicorp-consul-dev, which was RM'ed in #1055054 * Depends on golang-github-uber-jaeger-client-go-dev, which I have asked to be RM'ed for the time being in #1060811 (the library is deprecated and vendors a bunch of stuff, so I don't want it in the archive without being actively used; refer to that package's README.source for more details) * Patches have been applied to use older versions of grpc and etcd as currently packaged Mathias signature.asc Description: This is a digitally signed message part
Bug#1060811: RM: golang-github-uber-jaeger-client-go -- ROM; no longer needed, deprecated upstream
Package: ftp.debian.org Severity: normal Please remove golang-github-uber-jaeger-client-go. It was packaged solely to support the packaging of golang-github-grafana-dskit (bug #1001989) which had been required for the packaging of Incus. However, upstream Incus has removed the dependency on golang-github-grafana- dskit, so I no longer need to package it. Given that golang-github-uber-jaeger-client-go is deprecated and packaged solely to support golang-github-grafana-dskit, I would prefer to not have it linger around in the archive when nothing depends on it. It has never been included in a stable release, and there are no reverse build deps in unstable. Thanks, Mathias signature.asc Description: This is a digitally signed message part
Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
Incus 0.4 has been uploaded to NEW. Mathias signature.asc Description: This is a digitally signed message part
Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
At the end of the weekend, I think packaging for Incus is at the point that we're ready for an upload to NEW once golang-github- canonical-lxd-dev clears. I have applied a patch to disable the loki logging integration for the time being and return an error if someone tries to configure it. Basic functionality seems to be working on my sid box: * Container creation/use/deletion * VM creation/use/deletion * lxd-to-incus for containers and VMs - Side note: I feel that currently lxd-to-incus is a bit aggressive in blindly renaming /var/lib/lxd/, /var/log/lxd/, and /var/cache/lxd/, as that breaks LXD if you try to re-start it after the migration and didn't auto-purge it at the end of lxd-to-incus. However, as I think the only time someone would run lxd-to-incus is in advance of removing LXD, I don't know if it's really too much of an issue to worry about or not... Untested are things like various storage backends, cluster mode, etc. I also went through and cleaned up the debian/ directory. If anyone else wants to play with the current packaging, I've pushed everything up to salsa. Mathias signature.asc Description: This is a digitally signed message part
Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
Late last night I successfully built Incus as a Debian package for the first time! ️ There are two blockers before we can perform the initial upload to NEW: 1 -- Remaining build deps: * We're still waiting on bin:golang-github-canonical-lxd-dev to make it through NEW. * golang-github-grafana-dskit-dev still needs to be packaged, but Incus seems to only have a single use of that library in internal/server/loki/loki.go. Last night I just patched out any reference in loki.go to dskit/backoff so everything else could build. Obviously not an ideal approach. However, do we want to consider disabling loki support in Incus for the time being to facilitate getting Incus into Debian? I'll keep working on packaging dskit and eventually we can re-enable loki support once it's packaged. 2 -- Testing/QA: * General testing: Later today I'm planning to start testing Incus on a sid machine. I'm sure this will turn up various things to fix/tweak. Before uploading to NEW, at a minimum I'll want to make sure containers and VMs work out-of-the-box. * LXD migration: Simple migrations from LXD to Incus should work. * QA: Go through the debian/ directory in the Incus packaging to make sure it's all in good shape and is synced up with current LXD packaging work. Excited to be close to the finish line on this! Mathias signature.asc Description: This is a digitally signed message part
Bug#1050256: AppArmor breaks locking non-fs Unix sockets
On Sat, 2023-12-30 at 16:44 +0100, Salvatore Bonaccorso wrote:
> John, did you had a chance to work on this backport for 6.1.y stable
> upstream so we could pick it downstream in Debian in one of the next
> stable imports? Cherry-picking 1cf26c3d2c4c ("apparmor: fix apparmor
> mediating locking non-fs unix sockets") does not work, if not
> havinging the work around e2967ede2297 ("apparmor: compute policydb
> permission on profile load") AFAICS, so that needs a 6.1.y specific
> backport submitted to sta...@vger.kernel.org ?
>
> I think we could have people from this bug as well providing a
> Tested-by when necessary. I'm not feeling confident enough to be able
> to provide myself such a patch to sent to stable (and you only giving
> an Acked-by/Reviewed-by), so if you can help out here with your
> upstream hat on that would be more than appreciated and welcome :)
>
> Thanks a lot for your work!
I played around with this a bit the past week as well, and came to
the same conclusion as Salvatore did that commits e2967ede2297 and
1cf26c3d2c4c need to be cherry-picked back to the 6.1 stable tree.
I've attached the two commits rebased onto 6.1.y as patches to this
message. Commit e2967ede2297 needed a little bit of touchup to apply
cleanly, and 1cf26c3d2c4c just needed adjustments for line number
changes. I included some comments at the top of each patch.
With these two commits cherry-picked on top of the 6.1.69 kernel, I
can boot a bookworm system and successfully start a service within a
container that utilizes `PrivateNetwork=yes`. Rebooting back into an
unpatched vanilla 6.1.69 kernel continues to show the problem.
While I didn't see any immediate issues (ie, `aa-status` and log
files looked OK), I don't understand the changes in the first commit
well enough to be confident in sending these patches for inclusion in
the upstream stable tree on my own.
Mathias
This is a rebase of commit e2967ede2297 ("apparmor: compute policydb permission
on profile load") onto the 6.1.69 kernel release.
The original commit had a line that changed `kvzalloc()` -> `kvcalloc()` in
security/apparmor/policy_unpack.c, but that code doesn't appear in the 6.1 tree,
so I dropped it.
Also included is the one-line declaration of `struct aa_perms default_perms` in
security/apparmor/file.c which was introduced in commit 408d53e923bd ("apparmor:
compute file permissions on profile load").
Tested-by: Mathias Gibbens
diff --git a/security/apparmor/apparmorfs.c b/security/apparmor/apparmorfs.c
index 7160e7aa5..aaba936e1 100644
--- a/security/apparmor/apparmorfs.c
+++ b/security/apparmor/apparmorfs.c
@@ -633,7 +633,7 @@ static void profile_query_cb(struct aa_profile *profile, struct aa_perms *perms,
state = aa_dfa_match_len(dfa, profile->policy.start[0],
match_str, match_len);
if (state)
- aa_compute_perms(dfa, state, );
+ tmp = *aa_lookup_perms(profile->policy.perms, state);
}
aa_apply_modes_to_perms(profile, );
aa_perms_accum_raw(perms, );
diff --git a/security/apparmor/file.c b/security/apparmor/file.c
index e1b7e9360..8cf610a22 100644
--- a/security/apparmor/file.c
+++ b/security/apparmor/file.c
@@ -212,6 +212,7 @@ static u32 map_old_perms(u32 old)
*
* Returns: computed permission set
*/
+struct aa_perms default_perms = {};
struct aa_perms aa_compute_fperms(struct aa_dfa *dfa, unsigned int state,
struct path_cond *cond)
{
diff --git a/security/apparmor/include/perms.h b/security/apparmor/include/perms.h
index 13f20c598..de9631edb 100644
--- a/security/apparmor/include/perms.h
+++ b/security/apparmor/include/perms.h
@@ -133,6 +133,17 @@ extern struct aa_perms allperms;
xcheck(fn_for_each((L1), (P), (FN1)), fn_for_each((L2), (P), (FN2)))
+extern struct aa_perms default_perms;
+
+static inline struct aa_perms *aa_lookup_perms(struct aa_perms *perms,
+ unsigned int state)
+{
+ if (!(perms))
+ return _perms;
+
+ return &(perms[state]);
+}
+
void aa_perm_mask_to_str(char *str, size_t str_size, const char *chrs,
u32 mask);
void aa_audit_perm_names(struct audit_buffer *ab, const char * const *names,
@@ -141,8 +152,6 @@ void aa_audit_perm_mask(struct audit_buffer *ab, u32 mask, const char *chrs,
u32 chrsmask, const char * const *names, u32 namesmask);
void aa_apply_modes_to_perms(struct aa_profile *profile,
struct aa_perms *perms);
-void aa_compute_perms(struct aa_dfa *dfa, unsigned int state,
- struct aa_perms *perms);
void aa_perms_accum(struct aa_perms *accum, struct aa_perms *addend);
void aa_perms_accum_raw(struct aa_perms *accum, struct aa_perms *addend);
void aa_profile_match_label(struct aa_profile *profile, struct aa_label *label,
diff --git a/security/apparmor/include/policy.h b/security/apparmor/include/policy.h
index 639b5b248..230ef5007 100644
--- a/security/apparmor/include/policy.h
+++ b/security/apparmor/include/policy.h
@@ -7
Bug#1059471: ITP: golang-github-maxatome-go-testdeep -- Extremely flexible golang deep comparison
Package: wnpp Severity: wishlist Owner: Mathias Gibbens X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-maxatome-go-testdeep Version : 1.13.0-1 Upstream Author : Maxime Soulé * URL : https://github.com/maxatome/go-testdeep * License : BSD-2-clause Programming Lang: Go Description : Extremely flexible golang deep comparison go-testdeep is historically a go rewrite and adaptation of wonderful Test::Deep perl. . In golang, comparing data structure is usually done using reflect.DeepEqual or using a package that uses this function behind the scene. . This function works very well, but it is not flexible. Both compared structures must match exactly and when a difference is returned, it is up to the caller to display it. Not easy when comparing big data structures. . The purpose of go-testdeep, via the td package and its helpers, is to do its best to introduce this missing flexibility using "operators", when the expected value (or one of its component) cannot be matched exactly, mixed with some useful comparison functions. This is a new dependency required to update golang-github-jarcoal- httpmock. signature.asc Description: This is a digitally signed message part
Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
On Mon, 2023-12-25 at 12:52 +0100, Raphael Hertzog wrote: > I would really like to see incus in unstable/testing and even in > bookworm-backports at some point. Given the large number of new/updated dependencies for Incus, it would be a lot of work to properly prepare a release for bookworm- backports once Incus gets into unstable. Not saying that it couldn't be done, but I don't know if it would be worth the effort. If you would like to use Incus on bookworm right now, probably the best approach would be to install the package from Stéphane's repo: https://github.com/zabbly/incus. On Mon, 2023-12-25 at 12:30 +, Free Ekanayaka wrote: > Yes, Mathias and I are working on uploading Incus to unstable. You > can follow the progress here: > > https://wiki.debian.org/Incus > > we're definitely close-ish now, but there are still a few things to > do. Yesterday I pulled the 0.4 release into the salsa packaging repo for Incus and updated d/control to reflect the various build dependencies. I've also updated the wiki page to reflect the current list of remaining dependencies needed to be packaged/updated. Probably the biggest bit of work left is updating the existing dependencies for golang-github-grafana-dskit -- I've pushed some packaging updates to the various salsa repos, but actually uploading will require testing reverse build deps and possibly coordinating updates in affected packages. Mathias signature.asc Description: This is a digitally signed message part
Bug#1059454: ITP: golang-github-ovn-org-libovsdb -- An OVSDB Client Library
Package: wnpp Severity: wishlist Owner: Mathias Gibbens X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-ovn-org-libovsdb Version : 0.6.0-1 Upstream Author : Open Virtual Network * URL : https://github.com/ovn-org/libovsdb * License : Apache-2.0 Programming Lang: Go Description : An OVSDB Client Library OVSDB is the Open vSwitch Database Protocol. It's defined in RFC 7047 and is used mainly for managing configuration of Open vSwitch and OVN. This is a dependency for packaging Incus (ITP #1042989). signature.asc Description: This is a digitally signed message part
Bug#1059453: ITP: golang-github-openfga-go-sdk -- OpenFGA SDK for Go
Package: wnpp Severity: wishlist Owner: Mathias Gibbens X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-openfga-go-sdk Version : 0.3.3-1 Upstream Author : OpenFGA * URL : https://github.com/openfga/go-sdk * License : Apache-2.0 Programming Lang: Go Description : OpenFGA SDK for Go This is an autogenerated Go SDK for OpenFGA. It provides a wrapper around the OpenFGA API definition (https://openfga.dev/api). . OpenFGA is designed to make it easy for application builders to model their permission layer, and to add and integrate fine-grained authorization into their applications. OpenFGA’s design is optimized for reliability and low latency at a high scale. This is a dependency for packaging Incus (ITP #1042989). signature.asc Description: This is a digitally signed message part
Bug#1059455: ITP: golang-github-cenkalti-rpc2 -- Bi-directional RPC
Package: wnpp Severity: wishlist Owner: Mathias Gibbens X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-cenkalti-rpc2 Version : 1.0.0-1 Upstream Author : Cenk Altı * URL : https://github.com/cenkalti/rpc2 * License : Expat Programming Lang: Go Description : Bi-directional RPC rpc2 is a fork of net/rpc package in the standard library. The main goal is to add bi-directional support to calls. That means server can call the methods of client. This is not possible with net/rpc package. In order to do this it adds a *Client argument to method signatures. This is a dependency for packaging golang-github-ovn-org-libovsdb. signature.asc Description: This is a digitally signed message part
Bug#1059456: ITP: golang-github-cenkalti-hub -- Simple PubSub library
Package: wnpp Severity: wishlist Owner: Mathias Gibbens X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-cenkalti-hub Version : 1.0.2-1 Upstream Author : Cenk Altı * URL : https://github.com/cenkalti/hub * License : Expat Programming Lang: Go Description : Simple PubSub library This library provides a simple event dispatcher for the publish/subscribe pattern. This is a dependency for packaging golang-github-cenkalti-rpc2. signature.asc Description: This is a digitally signed message part
Bug#1059449: game-data-packager: Fate of Atlantis fails to start without "scumm:" prefix
Package: game-data-packager Version: 76 Severity: normal After building and installing the package for Indiana Jones and the Fate of Atlantis, it fails to start because scummvm now knows about two "atlantis" games: "scumm:atlantis" and "cryomni3d:atlantis". Without the "scumm:" prefix in the Exec statement of the generated .desktop file, nothing happens when trying to launch the game. > --- a/fate-of-atlantis-en-data.desktop2023-12-25 20:44:49.888531966 > + > +++ b/fate-of-atlantis-en-data.desktop2023-12-25 20:44:46.200557922 > + > @@ -6,4 +6,4 @@ > Terminal=false > Type=Application > Categories=Game;AdventureGame; > -Exec=scummvm -p /usr/share/games/fate-of-atlantis-en atlantis > +Exec=scummvm -p /usr/share/games/fate-of-atlantis-en scumm:atlantis signature.asc Description: This is a digitally signed message part
Bug#1025161: new version available
Control: tags -1 + wontfix Given Canonical's relicensing of LXD and imposing a CLA, it's unlikely that LXD will be updated beyond version 5.0.2+git20231211.1364ae4. This isn't to say it will be impossible to do so, but I'm not planning to wade through the necessary license checks of each source file in newer LXD releases. Once Incus is fully packaged for Debian, that will be the recommended path forward for users beginning with the trixie release. Mathias signature.asc Description: This is a digitally signed message part
Bug#1058592: LXD licensing changes and future for Debian packaging
Thanks, Free and Stéphane. Based on your comments, I think the best path forward will be to keep LXD packaging as-is for the trixie release, although its version will be stuck at the 5.0 LTS snapshot unless someone else steps in to further update it. I don't want to try to do any potentially tricky transition from LXD -> Incus right at system upgrade time that depends on interacting with a running daemon. But we can add a NEWS entry or similar to LXD's packaging informing people they should migrate to Incus prior to trixie+1 (forky) when LXD would be removed from Debian. Mathias On Wed, 2023-12-13 at 21:14 -0500, Stéphane Graber wrote: > Currently lxd-to-incus looks for the existing running LXD daemon to > validate the user configuration ahead of migrating the data to Incus, > that's why we need the LXD Go package for it, we actively interact with the > LXD API before shutting it down for the migration. > > So if you want to get rid of LXD in Trixie, you're going to want to run the > migration tool from preinst which doesn't seem ideal. Or at least put in a > debconf prompt to force the user to go and run the migration logic before > being allowed to continue with their system upgrade. > > An alternative is to turn the lxd and lxd-client packages into orphans, so > they can still be on the system and running when the user installs Incus > and runs the migration tool. Downside of this approach is that the user may > not be aware of this situation and as those binaries wouldn't be in the > archive anymore, there's no way for them to pull incus onto the system. > > Stéphane > > On Wed, Dec 13, 2023, 6:07 p.m. Free Ekanayaka wrote: > > > Hello Mathias, > > > > thanks for the thoughtful write-up. > > > > I'm pretty much on board with everything you said. > > > > The only detail I'm not totally sure about is whether it would actually > > be beneficial to have trixie ship LXD 5.0 (at commit ^1364ae4). It's > > true that it'd be an out-of-date LXD, but it might be handy for folks > > upgrading from bookworm and not wanting to contextually migrate to > > Incus, but rather leave that as a separate step later down the road. > > > > It's kind of a minor point, and something that I believe won't be such a > > big deal in practice. So I'd be also perfectly fine not shipping the LXD > > binary at all in trixie. > > > > Free signature.asc Description: This is a digitally signed message part
Bug#1058592: LXD licensing changes and future for Debian packaging
Control: retitle -1 LXD licensing changes and future for Debian packaging Control: severity -1 important Hi Jonathan, (Adding Free and Stéphane for their awareness) Free and I have been working on getting Incus packaged for Debian (see ITP#1042989 and https://wiki.debian.org/Incus). Free's getting a couple new dependencies into the archive, and we have to update some golang libraries, but once that's done we'll be able to get Incus officially into Debian. Up to this point, I had been planning to help maintain both LXD and Incus packaging for Debian so users could easily install either version. However, given Canonical's recent actions, I am pretty unmotivated to continue working on the LXD packaging. Their relicensing mess will make updating d/copyright for the next feature/LTS release a ton of work, and while LXD is still open source, it's very much a Canoncial-only project now with their CLA. (For the record, if anyone else is interested in helping maintain the LXD package, please feel free to do so!) So, what does the future of LXD in Debian look like? After some thought, this is what I'm envisioning: 1. Import the LXD stable-5.0 branch as a snapshot at the last commit before the relicensing announcement (upstream commit 1364ae4: "Merge pull request #12652") to get the last 5.0 LTS fixes/changes released under Apache-2.0. Importantly, this will pull in the import path changes when LXD was moved into Canonical's group on Github, which `lxd-to-incus` is expecting. 2. Upload this snapshot version of LXD to unstable, with lots of documentation about LXD likely not receiving further updates in Debian, and to consider switching to Incus. 2b. As part of that upload, introduce a bin:golang-github- canonical-lxd-dev package to facilitate building Incus. 3. Finish getting Incus packaged and into an equivalent shape as the current LXD packaging. Also make sure migrations from LXD to Incus work smoothly on Debian. 4. When Incus is sufficiently "mature" (either version 1.0 or we feel it would be proper to include in a stable Debian release), if no one else has expressed interest/willingness to maintain LXD's packaging in future Debian releases, we can modify src:lxd to no longer ship any binaries. Rather, it would then serve as a transitional package to src:incus for the bookworm -> trixie upgrade cycle. The only "real" binary package left would be bin:golang-github-canonical-lxd-dev, for use by Incus. 5. After the trixie release, file a RM bug for LXD. As for a timeline, we're roughly a year out from the trixie freezes starting, so that's how long we have to complete the LXD -> Incus transition for Debian. The alternative would be trixie shipping with a pretty old version of LXD, which I would like to avoid if possible. Other thoughts or opinions? Mathias signature.asc Description: This is a digitally signed message part
Bug#1057438: raft: FTBFS: Reason: UndefinedError("'style' is undefined")
Sphinx 7.0.0 dropped the `style` key (https://github.com/sphinx-doc/sphinx/pull/11381). Version 7.2.6 was uploaded to unstable early last month, causing this FTBFS. signature.asc Description: This is a digitally signed message part
Bug#1057116: bookworm-pu: package lxc/1:5.0.2-1+deb12u2
On Sat, 02 Dec 2023 19:17:28 + "Adam D. Barratt" wrote: > Please go ahead. Uploaded, thanks! Mathias signature.asc Description: This is a digitally signed message part
Bug#1057116: bookworm-pu: package lxc/1:5.0.2-1+deb12u2
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-lxc-de...@lists.alioth.debian.org, gib...@debian.org
Control: affects -1 + src:lxc
[ Reason ]
The version of lxc in bookworm fails to create ephemeral copies of
containers. This is affecting Debian users, as two different bugs have
been reported in addition to an upstream bug report.
A fix was merged into the upstream repo earlier today, and I have
cherry-picked it into the packaging for unstable which I have just
uploaded. I would like to get this fix into bookworm, as it is a
regression compared to lxc in bullseye.
[ Impact ]
The version of lxc currently in bookworm cannot create ephemeral copies
of containers.
[ Tests ]
The changes have been reviewed and accepted by the upstream developers.
I have tested that creation of normal and ephemeral containers works as
expected in bookworm with this patch.
[ Risks ]
Minor/none -- the specific variable being checked was fixed to be a
more correct one that could never be NULL, which was the root cause of
the bug. This does technically change the behavior of lxc by fixing the
bug, but I don't think there is any risk of a regression in other lxc
behavior.
[ Checklist ]
[*] *all* changes are documented in the d/changelog
[*] I reviewed all changes and I approve them
[*] attach debdiff against the package in (old)stable
[*] the issue is verified as fixed in unstable
[ Changes ]
Cherry-pick and rebase upstream commit
0e932812ae2ac4dec58e413c0d95d581385b9756, which has been merged into
the upstream repo. There is also renaming of the `bdev_type` variable
to `__bdev_type` which was included in the upstream commit; I have left
that in, so the changes to bookworm packaging can be a direct cherry-
pick of the upstream fix.
[ Other info ]
The source debdiff is attached.
diff -Nru lxc-5.0.2/debian/changelog lxc-5.0.2/debian/changelog
--- lxc-5.0.2/debian/changelog 2023-09-22 16:35:52.0 +
+++ lxc-5.0.2/debian/changelog 2023-11-30 01:17:33.0 +
@@ -1,3 +1,9 @@
+lxc (1:5.0.2-1+deb12u2) bookworm; urgency=medium
+
+ * Cherry-pick upstream fix for creating ephemeral copies (See #1001713)
+
+ -- Mathias Gibbens Thu, 30 Nov 2023 01:17:33 +
+
lxc (1:5.0.2-1+deb12u1) bookworm; urgency=medium
* Cherry-pick upstream "fix nftables syntax for IPv6 NAT" (Closes: #1049976)
diff -Nru lxc-5.0.2/debian/patches/0101-cherry-pick-fix-ephemeral-copies.patch lxc-5.0.2/debian/patches/0101-cherry-pick-fix-ephemeral-copies.patch
--- lxc-5.0.2/debian/patches/0101-cherry-pick-fix-ephemeral-copies.patch 1970-01-01 00:00:00.0 +
+++ lxc-5.0.2/debian/patches/0101-cherry-pick-fix-ephemeral-copies.patch 2023-11-30 01:17:33.0 +
@@ -0,0 +1,155 @@
+From 0e932812ae2ac4dec58e413c0d95d581385b9756 Mon Sep 17 00:00:00 2001
+From: Christian Brauner
+Date: Wed, 29 Nov 2023 15:57:04 +0100
+Subject: [PATCH] conf: fix ephemeral copies
+
+Don't rely on rootfs->bdev_type because that may be NULL. Use storage->type
+instead which can't be NULL.
+
+Co-Developed-by: Mathias Gibbens
+Signed-off-by: Mathias Gibbens
+Reported-by: Mathias Gibbens
+Signed-off-by: Christian Brauner
+---
+ src/lxc/conf.c| 21 -
+ src/lxc/conf.h| 4 ++--
+ src/lxc/confile.c | 4 ++--
+ src/lxc/storage/storage.c | 4 ++--
+ src/lxc/storage/storage.h | 2 +-
+ 5 files changed, 19 insertions(+), 16 deletions(-)
+
+diff --git a/src/lxc/conf.c b/src/lxc/conf.c
+index 9158713..e338ed7 100644
+--- a/src/lxc/conf.c
b/src/lxc/conf.c
+@@ -536,16 +536,21 @@ int lxc_rootfs_init(struct lxc_conf *conf, bool userns)
+ struct stat st;
+ struct statfs stfs;
+ struct lxc_rootfs *rootfs = >rootfs;
++ const char *type;
+
+ ret = lxc_storage_prepare(conf);
+ if (ret)
+ return syserror_set(-EINVAL, "Failed to prepare rootfs storage");
++ type = rootfs->storage->type;
++
++ if (!type)
++ return syserror_set(-EINVAL, "Storage type neither set nor automatically detected");
+
+ if (!is_empty_string(rootfs->mnt_opts.userns_path)) {
+ if (!rootfs->path)
+ return syserror_set(-EINVAL, "Idmapped rootfs currently only supported with separate rootfs for container");
+
+- if (rootfs->bdev_type && !strequal(rootfs->bdev_type, "dir"))
++ if (type && !strequal(type, "dir"))
+ return syserror_set(-EINVAL, "Idmapped rootfs currently only supports the \"dir\" storage driver");
+ }
+
+@@ -555,14 +560,12 @@ int lxc_rootfs_init(struct lxc_conf *conf, bool userns)
+ if (userns)
+ return log_trace(0, "Not pinning because container runs in user namespace");
+
+- if (rootfs->bdev_type) {
+- if (strequal(rootfs->bdev_type, "overlay") ||
+- strequal(rootfs->bdev_type, "overlayfs"))
+- return log_trace_errno(0, EINVAL, "Not p
Bug#947334: [pkg-lxc-devel] Bug#947334: lxc-checkpoint needs the criu package
On Wed, 2023-11-29 at 21:22 +0100, Salvatore Bonaccorso wrote: > On Sat, Nov 25, 2023 at 02:30:42PM +0000, Mathias Gibbens wrote: > > On Fri, 2023-11-24 at 11:37 +0100, Pierre-Elliott Bécue wrote: > > > Historically it was only in experimental, so I couldn't act upon > > > this bug. > > > > > > Now we can. I'd either add it as a Depends or as a Recommends. > > > > I don't think criu should be in Depends, as checkpointing/live > > migration of containers seems to be a less common use case, and the > > lxc package has been working fine in Debian for many years without > > it. I put it as a Suggests, since it does enhance the capability of > > lxc, but users who don't explicitly need CRIU won't be missing out > > on any functionality if they don't have it installed. However, I'll > > defer to group consensus on where exactly to list the criu packge > > for lxc. > > Suggests make sense. > > Note I have to resolve an issue with criu currently and is pending > autoremoval from testing. OK, for now I'll do an upload with criu in Suggests; we can easily change that if desired in a future upload. Mathias signature.asc Description: This is a digitally signed message part
Bug#947334: lxc-checkpoint needs the criu package
On Fri, 2023-11-24 at 11:37 +0100, Pierre-Elliott Bécue wrote: > Historically it was only in experimental, so I couldn't act upon this > bug. > > Now we can. I'd either add it as a Depends or as a Recommends. I don't think criu should be in Depends, as checkpointing/live migration of containers seems to be a less common use case, and the lxc package has been working fine in Debian for many years without it. I put it as a Suggests, since it does enhance the capability of lxc, but users who don't explicitly need CRIU won't be missing out on any functionality if they don't have it installed. However, I'll defer to group consensus on where exactly to list the criu packge for lxc. Mathias signature.asc Description: This is a digitally signed message part
Bug#889722: conflict with apparmor < 2.11.1-4?
Control: tags -1 + moreinfo Given the age of this bug, I think it's become a moot point. Any objections to closing it? Mathias signature.asc Description: This is a digitally signed message part
Bug#887787: lxc: CentOS 7 amd64 container can't be stopped
Control: tags -1 + moreinfo Hi Toni, Sorry that no one responded to this bug until now. Is this behavior still happening on a bookworm or sid system? I've just spent some time testing various containers, including a CentOS 7 one, and they are properly shutting down, both internally (`shutdown` and `halt`) as well as via `lxc-stop`. On Fri, 19 Jan 2018 22:51:13 +0100 Toni Mueller wrote: > Trying to 'lxc-stop -n centos' (name of the container) also does not > work. [snip] It would be great if lxc could prevent a container > misbehaving like that. `lxc-stop` does have the "--timeout" and "--kill" options which can be used to force stop a container that doesn't gracefully shutdown. Mathias signature.asc Description: This is a digitally signed message part
Bug#986638: lxc: CentOS 7 Container can't be started properly
Control: retitle -1 lxc: CentOS 7 containers require cgroup v1 controller Control: tags -1 + confirmed wontfix Hi Michael, Sorry that no one responded to this bug until now. The issue you are seeing is caused by the version of systemd in CentOS 7 expecting a cgroup v1 controller to be available, which isn't the case in recent versions of Debian. (Not sure exactly when, maybe starting with the bullseye release?) As a workaround, you can add "systemd.unified_cgroup_hierarchy=0" to your host kernel boot parameters which will switch systemd's cgroup setup from unified to hybrid. After rebooting, I was able to successfully start a working CentOS 7 container on my sid machine. There's nothing that lxc itself can do about this, so tagging with wontfix but keeping the bug open for anyone else who might encounter this issue in the future. Mathias signature.asc Description: This is a digitally signed message part
Bug#947334: lxc-checkpoint needs the criu package
Control: tags -1 + pending I think it's reasonable to Suggest criu in the bin:lxc package. If anyone has a strong opinion that it should rather be a Recommends, please let me know. Mathias signature.asc Description: This is a digitally signed message part
Bug#1052803: golang-github-gosexy-gettext: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 8 github.com/gosexy/gettext returned exit code 1
I have uploaded a fix for this as a NMU to the DELAYED/10 queue. A diff of the changes is attached. Mathias diff --git a/debian/changelog b/debian/changelog index ef627bd..3c5bb15 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +golang-github-gosexy-gettext (0~git20130221-2.2) unstable; urgency=medium + + * Non-maintainer upload. + * Run tests with LC_ALL=en_US.utf8 (Closes: #1052803) + + -- Mathias Gibbens Fri, 10 Nov 2023 19:12:55 + + golang-github-gosexy-gettext (0~git20130221-2.1) unstable; urgency=medium [ Dr. Tobias Quathamer ] diff --git a/debian/control b/debian/control index d1364e1..414b835 100644 --- a/debian/control +++ b/debian/control @@ -5,6 +5,7 @@ Maintainer: Steve Langasek Build-Depends: debhelper (>= 11~), dh-golang, golang-any, + locales-all Standards-Version: 4.2.1 Homepage: https://github.com/gosexy/gettext XS-Go-Import-Path: github.com/gosexy/gettext diff --git a/debian/rules b/debian/rules index 2d9b72c..1451b07 100755 --- a/debian/rules +++ b/debian/rules @@ -20,7 +20,7 @@ override_dh_auto_build: rm obj-*/src/github.com/gosexy/gettext/examples/*/*.pot override_dh_auto_test: - LC_ALL=C.UTF-8 dh_auto_test + LC_ALL=en_US.utf8 dh_auto_test get-orig-source: rm -rf $(PKG) signature.asc Description: This is a digitally signed message part
Bug#1052803: Help fixing a gettext translation test
Hi all, I'm working on fixing bug #1052803 for golang-github-gosexy-gettext. That package's tests started failing, and I'm pretty sure it was caused by the upload of src:glibc 2.37-8 which backported a patch from bug #874160 that treats language encodings like C.UTF-8 as the C locale. This change effectively "turns off" translations, unless you specify some specific encoding like "en_US.utf8". While I can apply the attached patch that fixes the tests, it feels less than ideal. And as this will be a NMU to prevent the package from being AUTORM'ed and taking src:lxd along with it, I'd like to fix this properly. I'm just not familiar enough with gettext to know if there's a better solution. A simple reproducer is listed below. On a sid system, the first invocation will fail to return the properly translated string, but the second will (substitute with your preferred locale). Thanks for any advice! Mathias (BCC: bug #1052803) > $ dget > https://deb.debian.org/debian/pool/main/g/golang-github-gosexy-gettext/golang-github-gosexy-gettext_0~git20130221-2.1.dsc > $ cd golang-github-gosexy-gettext-0~git20130221/ > $ LC_ALL=C.UTF-8 LANGUAGE="es_MX.utf8" TEXTDOMAINDIR=./examples/ gettext -d > example "Hello, world!" > $ LC_ALL=en_US.utf8 LANGUAGE="es_MX.utf8" TEXTDOMAINDIR=./examples/ gettext > -d example "Hello, world!" diff --git a/debian/control b/debian/control index d1364e1..18690eb 100644 --- a/debian/control +++ b/debian/control @@ -4,7 +4,7 @@ Priority: optional Maintainer: Steve Langasek Build-Depends: debhelper (>= 11~), dh-golang, - golang-any, + golang-any, locales-all Standards-Version: 4.2.1 Homepage: https://github.com/gosexy/gettext XS-Go-Import-Path: github.com/gosexy/gettext diff --git a/debian/rules b/debian/rules index 2d9b72c..1451b07 100755 --- a/debian/rules +++ b/debian/rules @@ -20,7 +20,7 @@ override_dh_auto_build: rm obj-*/src/github.com/gosexy/gettext/examples/*/*.pot override_dh_auto_test: - LC_ALL=C.UTF-8 dh_auto_test + LC_ALL=en_US.utf8 dh_auto_test get-orig-source: rm -rf $(PKG) signature.asc Description: This is a digitally signed message part
Bug#1055079: dqlite: flaky tests on ppc64el
Source: dqlite Version: 1.16.0-1 Tests seem flaky on ppc64el -- on the buildds they fail[0], but building the package on the ppc64el porter box (platti.d.o) succeeds. None of the other architectures seem to have issues with the tests. Mathias [0] -- https://buildd.debian.org/status/fetch.php?pkg=dqlite=ppc64el=1.16.0-1=1698707253=0 signature.asc Description: This is a digitally signed message part
Bug#1053885: manpages generation for many commands is flawed
Hi Osamu, Thanks for noticing and reporting this. I've looked into it a bit, and I think it would be appropriate to report this to the spf13/cobra project[0]. From my reading of the LXD/Incus use of the library, I don't think they're doing anything "special" that would affect the behavior generating the manpages. If you do report it there, we can re- assign this bug to src:golang-github-spf13-cobra. Mathias [0] -- https://github.com/spf13/cobra signature.asc Description: This is a digitally signed message part
Bug#1055010: golang-github-nats-io-nkeys: CVE-2023-46129
Control: block 1055011 by 1055010 I've pushed the packaging updates for the latest release to salsa, but the fix introduces a regression in golang-github-nats-io-jwt, which I have reported upstream at https://github.com/nats-io/jwt/issues/211. Mathias signature.asc Description: This is a digitally signed message part
Bug#987619: ITP: golang-github-dgryski-go-rendezvous -- Go implementation of rendezvous hashing
I've just bumped into this package being a dependency of updating another golang library, and since it's so simple I've gone ahead with the packaging and uploaded to the NEW queue. Mathias signature.asc Description: This is a digitally signed message part
Bug#1001989: ITP: golang-github-grafana-dskit -- Distributed systems kit
Control: owner -1 ! All the dependencies should now be packaged in the archive, so I'll begin working on this package for upload to NEW shortly. Mathias signature.asc Description: This is a digitally signed message part
Bug#1053663: libraft2: Consider switching upstream to cowsql/raft
Hi Free and Laszlo, On Sat, 2023-10-14 at 10:31 +0100, Free Ekanayaka wrote: > As a consequence, I've renamed the libraft2 binary package to > libraft0. Note that libraft0 already exists in bullseye, but there's > nothing depending on it, so even in the weird case where somebody > downloads libraft0 from sid and installs it in bullseye, nothing > should break. Free, have you tested the upgrade path from a bullseye system with libraft0 installed incrementally through to sid? Even though it's probably a remote edge case, we should make sure the upgrade path works smoothly. (Both with just libraft0 installed directly, as well as indirectly by something like dqlite.) I've looked over the current packaging in salsa, and pushed a few commits cleaning up the packaging a bit. I have two remaining comments: First, it looks like you've intending to introduce a libraft-tools package, but it is currently empty -- do you mean to install something for that binary package? Also, its short description is a copy of libraft0's. Second, there's an existing patch in the packaging -- could that be included in the upstream code so we can eliminate the Debian-specific bit? Mathias signature.asc Description: This is a digitally signed message part
Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
On Sun, 2023-10-08 at 12:19 +0100, Free Ekanayaka wrote: > It seems that v6 of golang-github-checkpoint-restore-go-criu is in > experimental: > > https://packages.debian.org/experimental/golang-github-checkpoint-restore-go-criu-dev > > Not sure if there are blockers for it to move to unstable (maybe we'd > need to drop the patch currently applied to the LXD package?). 31/35 of the rdeps of golang-github-checkpoint-restore-go-criu build fine with v6.3.0 from experimental -- the big blocker is runc. Its most recent release (1.1.9) still depends on v5, although in the upstream main branch it's been switched to v6. Given that runc is a fundamental container library, I'll want to confer with the Go Packaging Team on how to move forward with this. (And LXD currently has a patch to revert the simple use of go-criu, so when v6 lands in unstable that's a simple thing to remove.) > Yes, agrred. Incus 0.1 has now been released, and I've updated the > salsa repository accordingly. > > I've also switched the packaging branch from debian/experimental to > debian/unstable, as actually I don't see a reason for not uploading > to unstable at this stage. Fine by me -- for a brand new package there doesn't seem to be much reason to first target experimental, in my opinion. > Once Incus 1.0 LTS is out we could opt for uploading only LTS updates > to unstable and development releases to experimental. That's the mental idea I've had for LXD as well, although I haven't actually done that yet. One of the tricky things would be managing two distinct upstream branches (upstream-lts and upstream-dev maybe?) and then merging Debian-specific packaging changes from unstable <-> experimental. > > Just a minor note -- if LXD keeps its established release > > schedule, I'm expecting LXD 6.0.x to ship in trixie. > > Yes, although I would personally keep Debian's LXD at version 5.0.x > for trixie and point users to the lxd-to-incus migration tool, to > migrate from LXD 5.0.x to Incus 1.0.x, which should be be a superset > of LXD 6.0.x. > > That's of course just [my] take, I understand that there might be > interest from other DDs/users (e.g. you) to update the Debian's > package to LXD 6.0.x. With my DD hat on, I don't want to artificially hold back the version of LXD in trixie solely to make life easier for Incus -- especially if there's a 6.0 LTS release out with plenty of time before freezes start. Doing so would be a disservice to users wishing to run LXD and have the latest LTS release available in trixie. I know there will be a growing delta between LXD and Incus as time goes on, but I would also suspect Incus will want to support migrations from newer versions of LXD as best as it can. > > > Currently in unstable there are only three rdeps of src:raft: > > dqlite, golang-github-canonical-go-dqlite, and lxd. So it would > > certainly be doable to switch the upstream of src:raft -- if Laszlo > > is open to doing so, it should be a pretty easy transition. > > Probably the trickiest thing would be the versions: I'd like to > > avoid a package epoch bump if possible, and we'd also have to > > consider the .so versioning. > > Why do think an epoch is needed? I believe it can be done without > epochs. Anyway, if the idea gets consenus I'll coordinate with Laszlo > about that. Looks like you've picked an initial release version of 0.17.7, so I guess that side-steps the epoch bump issue in Debian's packaging, but I don't know about resetting the .so version back to zero. Is there anything in Policy about a "backwards" transition? While there wouldn't be API compatibility, this would introduce two different "libraft.so.0" files into the archive. (And a future ".so.1" and ".so.2".) Maybe we could find another C library that changed its upstream to see how they handled it? Mostly I just don't want to accidentally cause a (subtle) mess somewhere down the road. This evening I created an initial wiki page as well, which at the moment is just tracking some of the remaining dependencies for Incus' packaging: https://wiki.debian.org/Incus. Mathias signature.asc Description: This is a digitally signed message part
Bug#1052191: unicode-data: Please update for the new 15.1 release
Hi, Is there a plan for the transition from 15.0 -> 15.1? golang-github- mattn-go-runewidth has FTBFS bug #1052819 fixed in unstable, but blocked on migration to testing. It's on the AUTORM list about a month out, and I'd like to avoid its removal from testing if possible. Thanks, Mathias signature.asc Description: This is a digitally signed message part
Bug#1052803: golang-github-gosexy-gettext: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 8 github.com/gosexy/gettext returned exit code 1
Hi Steve, This library is a dependency of LXD and the hopefully soon to be packaged Incus, so I'd like to prevent it from being AUTORM'ed from testing in a month. Have you had a chance to look into this build failure? Also, if you'd like to move the package to being team-maintained with the Go Packaging Team, I'd be happy to help with any further attention this package might need in the future. Thanks, Mathias signature.asc Description: This is a digitally signed message part
Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
Control: reassign -1 wnpp Control: retitle -1 ITP: Incus -- Powerful system container and virtual machine manager Control: severity -1 wishlist Control: block -1 by 1052536 1001989 I'm converting this bug to an ITP, as there's clearly sufficient interest in the packaging of Incus. Plus, it will help track any dependencies that need to be packaged/updated for Debian. On Tue, 2023-09-19 at 08:44 +0100, Free Ekanayaka wrote: > The dependencies should be pretty much the same as LXD 5.16, except for > cowsql, and for a few dependencies that actually got dropped wrt LXD. So > that part should be relatively straightforward if you have already done > some work for LXD 5.16. There are two dependencies still in progress that are needed to properly build the latest feature release of LXD in Debian: golang- github-grafana-dskit (ITP#1001989; it has one dependency [golang- github-uber-jaeger-client-go] currently in NEW before I can package it) and updating golang-github-checkpoint-restore-go-criu to v6 (currently on v5, with a patch to undo its use in the current LXD packaging). > The idea is to have Incus follow a release scheme similar to LXD, with > LTS releases every 2 years or so, and "development" releases in > between. The first LTS release would probably come out early next year. That sounds great, and will fit nicely into the trixie development cycle! > We were thinking more or less the same, but with a difference: what > about uploading to Debian only the LTS updates of LXD for now (that > means the 5.0.x releases) and start uploading the Incus development > releases (once the first is out)? That seems reasonable to me. I know people occasionally ask for the latest version of LXD, which someday I might upload to experimental on a "best effort" basis, but the main packaging for LXD will follow the LTS releases. Prior to Incus' 1.0 LTS release, I think it would be great to upload development releases to facilitate testing by interested users. > Once trixie gets released it would contain the latest LXD 5.0.x release > (which upstream supports until June 2027), and the latest Incus LTS > release. Bookworm users can upgrade to trixie and then migrate their > deployments to Incus using the lxd-to-incus tool, if they wish to. Just a minor note -- if LXD keeps its established release schedule, I'm expecting LXD 6.0.x to ship in trixie. We will definitely want test the transition path and ensure there's good documentation in place for the trixie release. > As for now cowsql's raft is compatible with dqlite's raft, and I plan to > maintain that compatibility, at least as far as the LXD+dqlite stack is > concerned (which is what matters for Debian). > > What I'd propose would be to change the upstream of the libraft package > in Debian from canonical/raft to cowsql/raft, and I could (co-?)maintain > the libraft package as well as the dqlite one, making sure they work > together (that might help Laszlo too, taking some work off his plate, I > can reach out to him and ask). Currently in unstable there are only three rdeps of src:raft: dqlite, golang-github-canonical-go-dqlite, and lxd. So it would certainly be doable to switch the upstream of src:raft -- if Laszlo is open to doing so, it should be a pretty easy transition. Probably the trickiest thing would be the versions: I'd like to avoid a package epoch bump if possible, and we'd also have to consider the .so versioning. On Sun, 2023-09-24 at 15:54 +0100, Free Ekanayaka wrote: > I've created the Salsa repository for the incus Debian source package: > > https://salsa.debian.org/go-team/packages/incus +1 > > It's still very early on and it's not working yet (I've mostly rebranded > the debian/ directory of the lxd Debian source package), but it's a > start, so perhaps we might already have something kind of working by the > time the first Incus release is out. At least initially, I'd like to keep the packaging for LXD and Incus as similar as possible. I know over time things will diverge, but for now I think keeping the delta between packages small will be beneficial. > I've now filed an ITP for cowsql: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052536 Saw that, thanks! Mathias signature.asc Description: This is a digitally signed message part
Bug#1052934: plocate: Error running inside LXC container using systemd service (timer) with PrivateNetwork=true set
Control: tags -1 + confirmed Hi Alastair and Steinar, The root cause of this issue was found to be a bug in apparmor that was fixed in kernel 6.2, but not yet backported to the 6.1 LTS tree for bookworm. Lots of details are in bug #1050256. For now I won't reassign this to src:linux, so hopefully it's easier to find by anyone else who runs into the issue. I also updated the LXC/LXD wiki.d.o pages. For now, possible workarounds include modifying the service definitions, installing a kernel from bookworm-backports on the host, or disabling apparmor protections for the container. We were hoping a fix would be ready in time for the 12.2 point release, but it's looking like that probably won't happen. Mathias signature.asc Description: This is a digitally signed message part
Bug#1050256: [pkg-apparmor] Bug#1050256: autopkgtest fails on debci
On Tue, 2023-09-19 at 07:17 +0200, Salvatore Bonaccorso wrote: > On Sun, Sep 17, 2023 at 12:01:37PM +0530, intrigeri wrote: > > In the last month or so, a number of people from various Debian teams > > and other distributions have been tracking down a regression that > > affects systems upgraded to Bookworm: services that use certain > > systemd facilities such as PrivateNetwork=yes fail to start in LXC/LXD > > containers. Among other things, this breaks the autopkgtests of many > > packages, such as systemd, on ci.debian.net (#1050256). This was > > tracked down to a kernel regression, for which a fix landed in Linux > > 6.2: > > > > 1cf26c3d2c4c apparmor: fix apparmor mediating locking non-fs unix sockets > > > > Work is ongoing to backport the fix to linux-stable/linux-6.1.y. > > I'm Cc'ing John and Mathias who have been working on this. > > > > FYI, ideally this would be fixed in the upcoming Bookworm > > point-release (12.2, early October). > > Thanks for the details. Has this already been sent it to the stable > maintainers? I do not see it yet on the stable list. I believe that John has been working on the fix for the 6.1 branch, although I don't know what the status is. I don't have the necessary familiarity with apparmor internals to attempt to backport the fix myself, but I'll be very happy to test once it's available. Mathias signature.asc Description: This is a digitally signed message part
Bug#1052479: bookworm-pu: package lxc/1:5.0.2-1+deb12u1
On Sat, 2023-09-23 at 21:29 +0100, Adam D. Barratt wrote: > > Please go ahead. Uploaded, thanks! Mathias signature.asc Description: This is a digitally signed message part
Bug#1052007: bookworm-pu: package lxcfs/5.0.3-1+deb12u1
On Sat, 2023-09-23 at 20:36 +0100, Adam D. Barratt wrote: > Please go ahead. Uploaded, thanks! Mathias signature.asc Description: This is a digitally signed message part
Bug#1036818: lxcfs: /proc/cpuinfo is empty inside lxc on armel and armhf
Control: fixed -1 5.0.3-1+deb12u1 Also fixed in version 5.0.3-1+deb12u1 which was just accepted into stable-p-u. signature.asc Description: This is a digitally signed message part
