Package Details: ipget 0.6.0-1

Git Clone URL: https://aur.archlinux.org/ipget.git (read-only, click to copy)
Package Base: ipget
Description: wget for IPFS: retrieve files over IPFS and save them locally.
Upstream URL: https://github.com/ipfs/ipget
Keywords: IPFS wget
Licenses: MIT
Submitter: Kubuxu
Maintainer: redfish
Last Packager: redfish
Votes: 12
Popularity: 0.000000
First Submitted: 2016-02-26 15:30 (UTC)
Last Updated: 2020-05-24 02:40 (UTC)

Dependencies (6)

Required by (0)

Sources (1)

Pinned Comments

Latest Comments

bionade24 commented on 2020-11-26 11:22 (UTC)

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

tobol commented on 2020-11-26 10:47 (UTC)

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

panic: qtls.ClientSessionState not compatible with tls.ClientSessionState

Martian commented on 2020-06-02 11:35 (UTC) (edited on 2020-06-02 11:35 (UTC) by Martian)

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

bionade24 commented on 2019-01-09 18:24 (UTC) (edited on 2019-01-12 19:11 (UTC) by bionade24)

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.

revel commented on 2018-11-23 17:16 (UTC)

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

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

imrehg commented on 2018-05-31 17:25 (UTC)

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.

eschwartz commented on 2018-05-31 13:55 (UTC) (edited on 2018-05-31 13:56 (UTC) by eschwartz)

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.

imrehg commented on 2018-05-31 13:40 (UTC)

@frakspace, thanks for hunting down the issue! :D

frankspace commented on 2018-05-31 13:33 (UTC)

@imrehg Ah, I figured out the problem. Your version-3 pkgrel works for me, but ONLY if I replace "gcc-go" (which is what I originally had installed) with "go". If I tamper with the specified version number so that the PKGBUILD accepts gcc-go, the same failure occurs. So, that was what was wrong, gcc-go is simply broken and not an acceptable substitute. Thanks!

frankspace commented on 2018-05-31 13:03 (UTC)

@imrehg I'm not really sure. It spends a considerable amount of time downloading something. Whether it's succeeding, I don't really know, but if the following diagnostics are useful to you, here are some find commands I tried while in the directory where I tried to build it:

[ipget]$ find . -iname *flood*
./src/src/github.com/libp2p/go-floodsub
./src/src/github.com/libp2p/go-floodsub/floodsub_test.go
./src/src/github.com/libp2p/go-floodsub/floodsub.go
[ipget]$ find . -iname *libp2p*
./src/src/github.com/libp2p
./src/src/github.com/libp2p/go-libp2p-protocol
./src/src/github.com/libp2p/go-libp2p-peer
./src/src/github.com/libp2p/go-libp2p-net
./src/src/github.com/libp2p/go-libp2p-host
./src/src/github.com/libp2p/go-libp2p-crypto
./src/src/github.com/libp2p/go-libp2p-transport
./src/src/github.com/libp2p/go-libp2p-interface-connmgr
./src/src/github.com/libp2p/go-libp2p-peerstore
./src/src/github.com/libp2p/go-libp2p-interface-conn
[ipget]$ find . -iname *ultiadd*
./src/src/github.com/multiformats/go-multiaddr-net
./src/src/github.com/multiformats/go-multiaddr-net/multiaddr
./src/src/github.com/multiformats/go-multiaddr-net/multiaddr/multiaddr.go
./src/src/github.com/multiformats/go-multiaddr
./src/src/github.com/multiformats/go-multiaddr/multiaddr_test.go
./src/src/github.com/multiformats/go-multiaddr/multiaddr.go
[ipget]$ find . -iname *ultipar*
[ipget]$ find . -iname tar-utils
[ipget]$ find . -iname tar*
[ipget]$ find . -iname *utils

So I'm not positive what that means, but assuming I'm not a whole lot less competent at using find than I think I am, it looks like the deps from "whyrusleeping" don't exist anywhere. Or they're named something funny. Or I don't understand what's going on even more than I think. I hope it's of some use, anyway.

imrehg commented on 2018-05-31 12:46 (UTC) (edited on 2018-05-31 12:47 (UTC) by imrehg)

@frankspace that's weird, seems like go get fails for you? Looks like textflag.h should be used properly, since it's supplied by the go package.... Not sure I have a guess at this point...

imrehg commented on 2018-05-31 12:40 (UTC)

@Eschwartz well, how deep people go into a package and change how it is built? Here for example that means patching out part of the Makefile to work differently... Anyway it's done in pkgver 3, let me know if there's any outstanding "damn don't do it this way" remains.

frankspace commented on 2018-05-31 12:33 (UTC) (edited on 2018-05-31 12:45 (UTC) by frankspace)

This isn't working for me. Here's what happens:

==> Extracting sources...
  -> Extracting v0.3.0.tar.gz with bsdtar
==> Starting build()...
==> Installing extra dependencies
> github.com/libp2p/go-floodsub
# github.com/minio/blake2b-simd
src/github.com/minio/blake2b-simd/compress_amd64.go:21:5: error: reference to undefined name ‘avx2’
  if avx2 {
     ^
src/github.com/minio/blake2b-simd/compress_amd64.go:23:12: error: reference to undefined name ‘avx’
  } else if avx {
            ^
src/github.com/minio/blake2b-simd/compress_amd64.go:25:12: error: reference to undefined name ‘ssse3’
  } else if ssse3 {
            ^
# github.com/minio/sha256-simd
src/github.com/minio/sha256-simd/sha256blockAvx2_amd64.s:35:10: fatal error: textflag.h: No such file or directory
 #include "textflag.h"
          ^~~~~~~~~~~~
compilation terminated.

eschwartz commented on 2018-05-31 12:01 (UTC) (edited on 2018-05-31 12:01 (UTC) by eschwartz)

Thanks, but we've got perfectly serviceable packages for gx, and gx-go, which you can use instead of downloading prebuilt versions in make build that don't even do checksum verification.

Also the previous maintainer was an upstream dev who uploaded three non -bin packages (gx and gx-go as well) which all distributed his prebuilt binaries. -bin packages are not automatically bad though, don' worry. :)

imrehg commented on 2018-05-31 11:29 (UTC)

Done, built from source.

imrehg commented on 2018-05-31 10:42 (UTC)

Revising my last statement: now I see that it can be built without host IPFS client, as it will bootstrap itself. On the other hand, currently the version seems to be unbuildable (because of dependency errors). Thus I think there's a good path to make this package source-buildable - but for that likely upstream changes are needed, and in the meantime the binary distribution has to do. Will be looking into workarounds.

imrehg commented on 2018-05-31 09:37 (UTC)

And now I see why the binary distribution was provided first - the current build requires a working IPFS setup, as it pulls the dependencies from IPFS directly... Now that's something that a from-source build has to work around (and likely patch).

Also, I'm not sure in general that you can characterize AUR as "not a distribution center for [..] upstream prebuilt binaries". Search the package names for "-bin", and see how many prebuilt binaries are distributed. IMHO AUR is should aim for building from scratch, but the main reason of being is that "people don't have to package themselves" (not that they "can build themselves")... But that's a different discussion. Will be trying to fix this package up to build from source, if it's at all possible without an up-and-running IPFS client.

imrehg commented on 2018-05-31 09:14 (UTC)

@Eschwartz: With respect, my plan was bumping the verison first, so people can take advantage of the new version right away, and in the next couple of days update the package to build from source. That's a gradual improvement, and nobody else cared to do it yet, so...

eschwartz commented on 2018-05-30 20:23 (UTC)

That's not how you fix things. Don't adopt this and bump the pkgver but still pull the prebuilt binaries.

eschwartz commented on 2018-05-27 16:47 (UTC)

This needs to be fixed to conform to packaging standards and build from source, as I mentioned on the (now moved to community) comments page for gx.

The AUR is not a distribution center for your upstream prebuilt binaries, we require that they are rebuilt from source.

Now would be a good time to update to the latest version, too.

dreieck commented on 2018-05-05 20:57 (UTC)

Out of date. Up to date release:

https://github.com/ipfs/ipget/archive/v0.2.5.tar.gz

RunningDroid commented on 2016-05-23 02:33 (UTC)

The .SRCINFO is out of date, the repository is at https://github.com/ipfs/ipget now.