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

Pin lock UI feedback

ipfs/go-ipfs

<!– 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

Description:

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 https://github.com/ipfs/community/blob/master/contributing.md#reporting-issues if your issue doesn’t fit either of those categories. Read https://github.com/ipfs/go-ipfs/blob/master/docs/github-issue-guide.md 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 synocommunity.com

SynoCommunity/spksrc

The author field on the package view on synocommunity.com/package/$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 synocommunity.com/register; - Tell me that you’ve registered, so we can link the two.

Started with some people here: https://github.com/SynoCommunity/spksrc/pull/2643#issuecomment-278968908 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

ipfs/go-ipfs

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 packages.synocommunity.com repository to rs3617xs+

SynoCommunity/spksrc

Hello, it seems there is a problem adding packages.synocommunity.com 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 … (packages.synocommunity.com was resolved to 104.31.94.179)

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
Host: packages.synocommunity.com
User-Agent: synology_broadwell_rs3617xs+ DSM6.0-8451 Update 2 (package)
Accept: */*
HTTP/1.1 422 UNPROCESSABLE ENTITY
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=/; domain=.synocommunity.com; HttpOnly
Server: cloudflare-nginx
CF-RAY: 2fb75a9440222348-FRA

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<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

linrunner/TLP

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 'http://repo.linrunner.de/fedora/tlp/repos/RPM-GPG-KEY-tlp' | 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) <tlp@warpnine.de>
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://pool.sks-keyservers.net --search-key 'tlp@warpnine.de'
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

ipfs/go-ipfs

From https://github.com/ipfs/infrastructure/commit/63887a6697f17eb8f932ab4dfec2524c9e7318cd#commitcomment-14734054 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: https://github.com/rht/go-ipfs/blob/48a33ffb673fb3eaf6d20cd7ca6bed04426a2abb/cmd/ipfs/daemon.go#L492-> 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