Hi Carsten! On Tue, 2022-04-05 at 16:43 +0200, Carsten Brandt wrote: > Hi, > > first thanks for the effort put into packaging LXD! Thanks for taking a look and providing your feedback! My day job's been keeping me quite busy, so sorry about the delay in replying to the list. > > I tried building lxd package on a fresh debian sid. > from the sources at https://salsa.debian.org/go-team/packages/lxd/ > using `dpkg-buildpackage -us -uc -b`, not sure if this is the correct > way but it seems to work fine so far. I personally use `gbp buildpackage` which I have setup to use sbuild for a minimal fresh and clean environment each build. Of course, there are several ways you can kick off a package build depending on your preferences. > > I have some feedback about some errors I got while building: > > ---- > > > > # github.com/canonical/go-dqlite/internal/bindings > > > src/github.com/canonical/go- > dqlite/internal/bindings/server.go:11:10: > > fatal error: dqlite.h: No such file or directory > > > 11 | #include <dqlite.h> > > > | ^~~~~~~~~~ > > > > > > compilation terminated. > > > > > > I fixed by it by installing libdqlite-dev > > This should probably be added as a build-dependency to lxd. > > See my comment after the next section. > > ---- > > > > > > github.com/canonical/go-dqlite/internal/bindings > > > google.golang.org/grpc/balancer/base > > > # github.com/canonical/go-dqlite/internal/bindings > > > src/github.com/canonical/go- > dqlite/internal/bindings/server.go:12:10: > > fatal error: raft.h: No such file or directory > > > 12 | #include <raft.h> > > > | ^~~~~~~~ > > > compilation terminated. > > > > > I fixed by it by installing libraft-dev > This should probably be added as a build-dependency to lxd. > Both libdqlite-dev and libraft-dev are listed as Build-Depends for golang-github-canonical-go-dqlite and Depends for its -dev package, which the LXD packaging then has a Build-Depends on. Depending on how you setup your build environment, you may have to manually ensure the various dependencies are available with something like `sudo apt build- dep golang-github-canonical-go-dqlite`. (`gbp` takes care of ensuring all dependencies are installed automatically, which is pretty cool.) > > ---- > > > github.com/lxc/lxd/lxd/cluster > > > # github.com/lxc/lxd/lxd/cluster > > > src/github.com/lxc/lxd/lxd/cluster/recover.go:166:15: undefined: > dqlite.ReconfigureMembershipExt > > > lxd requires golang-github-canonical-go-dqlite-dev >= 1.10.1 > > > Build dependency exists but it should also specify the minimum > version. > Yes, this is technically true. However, I don't plan to submit LXD to the NEW queue until all its new/updated dependencies are available in unstable. Therefore I think it may not make sense to start listing minimum versions of dependencies that I know will be satisfied in unstable when LXD finally lands in the archive. Of course, if team consensus is to explicitly call out minimum versions, it's easy enough to add. > > ---- > > > # github.com/lxc/lxd/lxd/vsock > > > src/github.com/lxc/lxd/lxd/vsock/vsock.go:17:31: too many > arguments > in > call to vsock.Dial > > > have (uint32, uint32, nil) > > > want (uint32, uint32) > > > src/github.com/lxc/lxd/lxd/vsock/vsock.go:22:28: too many > arguments > in > call to vsock.Listen > > > have (uint32, nil) > > > want (uint32) > > > > > > lxd requires golang-github-mdlayher-vsock to be at least version > 1.0.0 > > > Build dependency exists but it should also specify the minimum > version. > See previous comment. > ---- > > > I built the following packages locally (latest version from salsa > git): > > - golang-github-canonical-candid > - golang-github-canonical-go-dqlite > - golang-github-juju-aclstore > - golang-github-mdlayher-ndp > > other dependencies are from sid packages. > > I am currently stuck at building golang-github-mdlayher-vsock which > seems to require a newer version of the golang-github-mdlayher-socket > package which matches the state documented at > > https://gobby.debian.org/export/Teams/Go/lxd-dep-packaging Yes, that's probably the biggest sticking point right now. Updating golang-github-mdlayher-vsock requires an updated version of golang- github-mdlayher-socket, which in turn requires a version of golang- golang-x-sys from at least mid-March. (I've personally been using version 0.0~git20220325.3677212 locally.) However, `x/sys` is a "core" golang library and I am hesitant to try to update it myself just because of the vast number of rdeps. (767 in main as of this afternoon.) I did send an email to the Uploaders of that package asking if they could work on uploading a newer version, but haven't heard back yet. Ultimately if it gets to the point where all the other dependencies for LXD are in unstable, I guess I'd start tackling that update. :) > > is there anything I can do to help with in upgrading these? For any DDs that might be willing to sponsor NEW or updated packages I've been working on, here's a brief snapshot of the four packages that I think are ready for attention: * golang-github-juju-aclstore is NEW and ready for its initial upload; packaging work is staged on salsa under the go-team namespace. * golang-github-mdlayher-ndp is also NEW and ready for its initial upload; packaging work is staged on salsa under the go-team namespace. * golang-github-j-keck-arping has a version update from 1.0.0 -> 1.0.2 staged on salsa under the go-team namespace. Currently there are two rdeps in main, and both build successfully via `ratt` with the updated package. One other change was to move the tests to be run under autopkgtest, as one of them requires the cap_net_raw permissions. * The "problem" package in my LXD work has been golang-github- canonical-go-dqlite. It has tests that are sensitive to timing when running on slower hardware (ie, not a nice, powerful amd64 system). A few months ago I uploaded version 1.10.1, and it promptly failed on all the buildds. :) Since then the upstream developers have done some work to make the tests a little bit more resilient, but there are still random failures. Because of that, I've moved running this package's tests to autopkgtest and marked them as "flaky". I figure that will still allow tests to be run on a regular basis, but random test failures won't halt the package migration process. On salsa under the go-team namespace, I have a version update from 1.10.1 -> 1.11.0. There are no rdeps in main. Thanks, Mathias > > I have not much experience in Go but I have created debian packages > before. > > best regards, > > Carsten > > -- > cebe.cloud - Carsten Brandt > > cb@cebe.cloud > https://cebe.cloud/ >
Attachment:
signature.asc
Description: This is a digitally signed message part