Arch Linux User Repository

This PKGBUILD does not install the ipget binary with executable permissions.

In package(), this line:

install -Dm644 -t "${pkgdir}/usr/bin" ipget

should instead be

install -Dm755 -t "${pkgdir}/usr/bin" ipget

Hi, is anyone else having an issue building this package?

==> Making package: ipget 0.6.0-1 (Wed Feb 15 13:21:19 2023)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found v0.6.0.tar.gz
==> Validating source files with sha256sums...
    v0.6.0.tar.gz ... Passed
==> Extracting sources...
  -> Extracting v0.6.0.tar.gz with bsdtar
==> Starting prepare()...
==> Removing existing $pkgdir/ directory...
==> Starting build()...
../../../../pkg/mod/github.com/ipfs/go-ipfs@v0.5.1/core/node/libp2p/libp2p.go:10:2: missing go.sum entry for module providing package     github.com/libp2p/go-libp2p-connmgr (imported by github.com/ipfs/go-ipfs/core/node/libp2p); to add:
    go get github.com/ipfs/go-ipfs/core/node/libp2p@v0.5.1
==> ERROR: A failure occurred in build().
    Aborting...

Please rename this package to ipget-bin to comply with the Arch packaging guidelines.

When you've managed to compile gx and then ipget the binary is useless:

panic: qtls.ClientSessionState not compatible with tls.ClientSessionState

I'm unable to build and install this package. I haven't got time to dig it in. Following is the output of the error:

... cut ...
github.com/whyrusleeping/gx
# github.com/whyrusleeping/gx
./main.go:154:15: cannot use cli.BoolFlag literal (type cli.BoolFlag) as type cli.Flag in slice literal:
        cli.BoolFlag does not implement cli.Flag (Apply method has pointer receiver)
./main.go:242:3: undefined: cli.BoolTFlag
./main.go:246:15: cannot use cli.BoolFlag literal (type cli.BoolFlag) as type cli.Flag in slice literal:
        cli.BoolFlag does not implement cli.Flag (Apply method has pointer receiver)
./main.go:326:3: undefined: cli.BoolTFlag
./main.go:330:15: cannot use cli.BoolFlag literal (type cli.BoolFlag) as type cli.Flag in slice literal:
        cli.BoolFlag does not implement cli.Flag (Apply method has pointer receiver)
./main.go:334:15: cannot use cli.BoolFlag literal (type cli.BoolFlag) as type cli.Flag in slice literal:
        cli.BoolFlag does not implement cli.Flag (Apply method has pointer receiver)
./main.go:338:15: cannot use cli.BoolFlag literal (type cli.BoolFlag) as type cli.Flag in slice literal:
        cli.BoolFlag does not implement cli.Flag (Apply method has pointer receiver)
./main.go:431:17: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in slice literal:
        cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
./main.go:464:17: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in slice literal:
        cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
./main.go:513:3: undefined: cli.BoolTFlag
./main.go:513:3: too many errors
==> ERROR: A failure occurred in build().
    Aborting...
Error making: gx

Hi, I'm the new maintainer. At the moment, there is no new ipget version, but I'll check if there's something to update.

Hi, apparently one of the checksums is wrong/outdated.

go-floodsub.tar.gz ... FAILED https://pastebin.com/4mkRpFHe

Versioned makedepends: go/go-pie I understand. For the others, the versions are coming from the project's own requirements. And it's totally possible for users to get older versions (they haven't updated for a while, downgraded, etc...). So I half agree. Removed them for now, but I don't think it should be a general principle, as it's an extra clarity what tools you need, and it's an effective cross-check.

Dependencies: it is known upstream, if I read e.g. the later discussion of this issue https://github.com/ipfs/ipget/issues/48 For now, I've added this dependencies, but since they have a lot of other dependencies in turn, those has to be go get. Too bad that go get cannot be versioned.

I've added git to makedepends. The weird thing is that go provides go get, but it doesn't list git even as optdepends, hence didn't think of that. Anyways....

Skipping Makefile for now, and splitting the process into prepare and build. Do not use linking there yet, will have to look into that more.

It does seem to work with go-pie (just about 30% larger file is the result). Added it to optdepends.

Don't use versioned makedepends, we're a rolling release so it is impossible for users to get older versions. Also it prevents satisfying go via the go-pie package.

Did you report the missing deps as an upstream bug? Meanwhile it would make sense to download the github.com/repo/project/archive/${_project_commit_hash}.tar.gz in source=() then symlink them like you do with the ipget sources, rather than cloning unknown revisions. Oh, then too, git is not listed as a makedepends even though you decided to clone sources using go get.

> github.com/libp2p/go-floodsub
go: missing Git command. See https://golang.org/s/gogetcmd
package github.com/libp2p/go-floodsub: exec: "git": executable file not found in $PATH

There's no need to patch out the Makefile, it just runs

bin/gx-$ver --verbose install --global
go build

You could do that much yourself, with gx instead of bin/gx-$ver, since their Makefile is both dead simple and wrong.

Or use make gx_bin=/usr/bin/gx gx-go_bin=/usr/bin/gx-go build

Note: the go packaging guidelines are being rewritten, see https://wiki.archlinux.org/index.php/User:Foxboron/Go_packaging_guidelines

You should link sources in prepare() and it would probably make sense to export GOPATH then use that instead of ${srcdir} in many places.

You should test to see if go-pie can be used instead of go.