Hi Guix, After the recent Go 1.13 update, the test for mongo-tools package (currently at vervsion 3.4.0) fails with: ```flag provided but not defined: -test.testlogfileUsage of /tmp/guix-build-mongo-tools-3.4.24.drv-0/go-build972699285/b001/mongofiles.test: -convey-json When true, emits results in JSON blocks. Default: 'false' -convey-silent When true, all output from GoConvey is suppressed. -convey-story When true, emits story output, otherwise emits dot output. When not provided, this flag mirros the value of the '-test.v' flag -test.types string Comma-separated list of the types of tests to be run (default "unit")FAIL github.com/mongodb/mongo-tools/mongofiles 0.002sFAILcommand "go" "test" "-v" "github.com/mongodb/mongo-tools/mongofiles" failed with status 1``` I believe that this is related to a change in Go's testing module with 1.13: https://golang.org/doc/go1.13#testing For more information, also see the Go bug report: https://github.com/golang/go/issues/31859 Note that mongo-tools provides a number of tools in different Go packages, and the mongofiles tool is the only one that has this error. I have tried to adding a call to flag.Parse() in TestMain, which I added, as described in the documentation , but that did not resolve the problem. I'm not exactly sure why. The same fix worked for containerd .  https://golang.org/pkg/testing/#hdr-Main http://git.savannah.gnu.org/cgit/guix.git/commit/?id=13c8e747e86e39c0a8c6ec7da8c812d9bbcb682b I wonder if the difference is that mongofiles does not use the flag package directly, but flag.Parse() is being called in the wrong place in one of its dependencies. A note on versions: the problem persists in the latest release of mongo-tools in the 3.4 series, 3.4.24. I have not tried the other release series, 3.6, 4.0, and 4.2 because those require dependencies not yet packaged in Guix. I have opened a bug report upstream: https://jira.mongodb.org/browse/TOOLS-2482 Thoughts or suggestions? Best,Jack
Toggle quote (3 lines)> I have opened a bug report upstream: > https://jira.mongodb.org/browse/TOOLS-2482
Upstream reports, "MongoDB 3.4 is now EOL so it is no longer supported. For MongoDB Tools specifically, we're only making critical fixes to versions <4.2." Therefore, it seems like the thing to do is to work on updating our mongo-tools package. Best,Jack
(name . Jack Hill)(address . firstname.lastname@example.org)
Jack Hill <email@example.com> writes:
Toggle quote (13 lines)> On Sat, 20 Jun 2020, Christopher Baines wrote:>>> Do you have any examples of packages that are currently broken, and>> which you'd like to remove?>> Perhaps mongo-tools: https://issues.guix.gnu.org/39637>> It broke when Go was upgraded to 1.13, and changed the test library. I> fixed some other Go packages that ran into this issue, but it wasn't> as easy for mongo-tools. Our version is old, so it should be> updated. For various reasons, I don't see this package being fixed in> the short term.
mongo-tools is definitely failing to build, and it has been since the11th of Feb (2020) I think. It seems like you got further in understanding this than I did. Giventhat this seems like a test failure, and I don't think there's anythingto suggest that the actual functionality doesn't work, the course ofaction I see here is to disable either the failing tests, or running thetest suite entirely. I originally packaged MongoDB and mongo-tools for Guix, but that wasbefore the licence of MongoDB changed, so I'm not sure about the longterm future of the packages. Keeping the packages we have actuallybuilding though is still useful. Thanks, Chris
(name . Christopher Baines)(address . firstname.lastname@example.org)
On Mon, Jun 22, 2020 at 06:06:44PM +0100, Christopher Baines wrote:
Toggle quote (6 lines)> It seems like you got further in understanding this than I did. Given> that this seems like a test failure, and I don't think there's anything> to suggest that the actual functionality doesn't work, the course of> action I see here is to disable either the failing tests, or running the> test suite entirely.
Not having looked into it closely, I think that, in general, testfailures do indicate that actual functionality is broken. Of course it'sa different story in many cases since the Guix build environment is sounusual.