Contribute to Open Source. Search issue labels to find the right project for you!

Pin lock UI feedback


<!– Output From ipfs version --all) –>

Version information: 0.4.7

<!– Bug, Feature, Enhancement, Etc –>

Type: enhancement

<!– from P0 “Critical” to P5 “Relatively Unimportant”) –>

Priority: P2


Pinning operations take the pin lock, so that only one pinning operation can run at a time. When running ipfs pin add and another operation is currently running, it’ll sit and wait until it acquires the lock and only then start to run. During this time there’s no UI feedback.

Instead it should show something like “Waiting for other pin operations to finish… ok”.

I think apart from ipfs pin add, this also applies to ipfs pin rm and ipfs add.

<!– This is for you! Please read, and then delete this text before posting it. The go-ipfs issues are only for bug reports and directly actionable features. Read if your issue doesn’t fit either of those categories. Read if you are not sure how to fill in this issue. –>

Updated 21/03/2017 05:34 1 Comments

(re)Start properly crediting package authors on


The author field on the package view on$package is set to the uploader by default (not the Maintainer in INFO, as those don’t necessarily have the same value). Over time, that means that a lot of authors aren’t properly credited for their work. So, let’s fix that.

How it works: - Make sure you use your Github account name in the package Maintainer field; - Use your Github account name to register on; - Tell me that you’ve registered, so we can link the two.

Started with some people here: I’ll have to start comparing packages with the original PR’s for the rest…

Updated 24/02/2017 00:18 15 Comments

Gateway and readonly repo


The gateway tries to fetch, store, and serve any hash that is requested. It would be useful to be able to refine this behavior, e.g. for repos in readonly environments. The naming is the best I could come up with adhoc.

  • [ ] Gateway.Fetch ||= true config option: whether a hash that has been requested should be fetched from the network if it isn’t stored locally yet. If set to false, the gateway will immediately respond with a client error (4xx) if the requested stuff isn’t stored locally.
  • [ ] Datastore.Readonly ||= false config option: whether stuff that has been fetched (as in the above) should be stored locally, or discarded after sending it with the response.
Updated 14/01/2017 02:01

Broadwell - Problem adding repository to rs3617xs+


Hello, it seems there is a problem adding repository to rs3617xs+ - it reports “Invalid location”. The same procedure on RS2211 works well.

Here are the http request and reply sniffed from the network … ( was resolved to

GET /?package_update_channel=beta&unique=synology_broadwell_rs3617xs%2B&build=8451&language=csy&major=6&arch=broadwell&minor=0&timezone=Amsterdam HTTP/1.1
User-Agent: synology_broadwell_rs3617xs+ DSM6.0-8451 Update 2 (package)
Accept: */*
Date: Wed, 02 Nov 2016 11:47:48 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: __cfduid=d1523eb3770083bbc6dad219f752ed3ab1478087268; expires=Thu, 02-Nov-17 11:47:48 GMT; path=/;; HttpOnly
Server: cloudflare-nginx
CF-RAY: 2fb75a9440222348-FRA

<title>422 Unprocessable Entity</title>
<h1>Unprocessable Entity</h1>
<p>The request was well-formed but was unable to be followed due to semantic errors.</p>

(and one more POST request using the same parameters)

Updated 27/02/2017 16:12 11 Comments

Fedora repository GPG key concerns


Hi, thanks for the awesome tools! I’m concerned about the GPG key that you use for the Fedora repository. First of all, the appears to be expired:

$ curl -sL '' | gpg --with-fingerprint
pub  dsa1024/C2FB431C 2012-04-16 [expires: 2013-04-16]
      Key fingerprint = 8AD5 9D64 3341 C382 1333  3FBD C89A 1C1A C2FB 431C
uid                   Andreas Roederer (tlp Repository) <>
sub  elg1024/00C9A31B 2012-04-16 [expires: 2013-04-16]

Second, I could not find the key on any key servers I looked.

$ gpg --keyserver hkp:// --search-key ''
gpg: error searching keyserver: No data
gpg: keyserver search failed: No data

Also, I could not find any mention of the key or its fingerprint anywhere outside the repository.

Updated 19/01/2017 06:20 3 Comments

GC improvements


From in the context of ipfs/infrastructure#125

@jbenet added a note a day ago

do we need the period? isnt the watermark enough?

@lgierth commented on 63887a6 a day ago

This is an old commit – it ended up as 20m in master: e177f10

Periodic GC is run regardless of the GCPeriod option being present, from what I understand:> L507

We need periodic GC because for now only ipfs cat maybe-runs GC.

@rht commented on 63887a6 a day ago

The default value for GCPeriod is set here.

We need periodic GC because for now only ipfs cat maybe-runs GC.

The latter because surveying the entire repo for each core.Resolve is too expensive.

@jbenet commented on 63887a6 12 hours ago

The latter because surveying the entire repo for each core.Resolve is too expensive.

It should definitely happen on writes.

Also, we should have a way of not running GC again in the case that: - above gc watermark - runs gc once - gc does not drop storage below watermark - another write happens (no pinset removes) - running gc again will waste a ton of read time - another write should not trigger gc

MaybeGC could track when new unpinned things could happen: - set a dirty bit when things removed from pinset (things become cached) - set a dirty bit when things new writes without adding pins (new things cached) - maybeGC skips GC if dirty bit not set

Updated 06/03/2017 08:11 1 Comments

Fork me on GitHub