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

consider reordering to favor newer stuff


<!– Before filing an issue, please search the existing issues (both open and closed) to see if your report might be duplicate –> <!– Please don’t file an issue when you have a support question, send support questions to the mailinglist or ask them on IRC ( –>

<!– Tell us what is issue is about –> - Program: Authoritative, Recursor, dnsdist - Issue type: Feature request

Short description

<!– Explain in a few sentences what the issue/request is –> The order of linux distributions (especially Debian and Ubuntu) is really not ideal. It favors old things for no particular reason.


Web Browser

Steps to reproduce

I was looking for the repo info for Debian 9 Stretch (but half the time i’m looking for an Ubuntu or a different Debian, or potentially a RHEL).

  1. visit
  2. Click Debian
  3. See “powerdns authoritative server version 4.0.x” and expand it

Expected behaviour

There are a number of ways to improve this 1. Don’t auto expand the second level (distro releases) when someone expands the first level (distro brands) 2. Change the order to favor newer releases over older releases 3. Possibly split LTS out of the normal flow (they’re in a lot of ways a distinct product from normal releases – with a distinct customer base – consider RHEL vs. Fedora – they’re very related, but practically unrelated customers – same for CentOS, very related, but distinct customers) 4. Switch to a series of [ |v] drop downs instead of a tree, an example of that is used by the PPA system, as in: a. click “Technical details about this PPA” b. select an item in: Display sources.list entries for:

Actual behaviour

Tree auto expanded to show Debian 8 children which obscured the presence of Debian 9.

Note that it’s much worse for Ubuntu, the first entry expanded is 14.04 (the older LTS), the second is 16.04 (the latest LTS), the third is 16.10 (obsolete), the last is 17.04 (the current release).

Note: the behavior is also not very helpful at the next tier: If a user is looking for something, they probably only care about a single product (auth, dnsdist, recursor, metronome) – showing them all of the various versions of all the products they don’t want isn’t helpful.

w/ a dropdown, I’d probably preselect the latest release branch but have “master” above and all the older things below.

Other information


Make it easy for customers to pick the right product.


Updated 11/08/2017 08:55 1 Comments

Incorrect `repoSize` when using symbolic links


Version information:

go-ipfs version: 0.4.10-
Repo version: 5
System version: amd64/linux
Golang version: go1.8.3






If the .ipfs directory is a symbolic link the repoSize as returned by ipfs repo stat or ipfs stats repo will always return 9 bytes regardless of actual data stored

With symlink ``` ~$ ls -al lrwxrwxrwx 1 ipfs ipfs 9 Jun 22 2016 .ipfs -> ipfs_data drwxrwxr-x 5 ipfs ipfs 4096 Jul 12 01:25 ipfs_data

~$ ipfs repo stat NumObjects: 204114 RepoSize: 9 StorageMax: 800000000000 RepoPath: /home/ipfs/.ipfs Version: fs-repo@5 ```

Without symlink ~$ ipfs repo stat NumObjects: 204114 RepoSize: 49450734482 StorageMax: 800000000000 RepoPath: /home/ipfs/.ipfs Version: fs-repo@5

Updated 18/07/2017 02:21 1 Comments

Add User Instructions


These should include:

  • Where to download the file
  • How to install the fonts
  • Any dependencies / installation limitations
  • Link to full documentation for learning how to use the fonts
  • Licensing / crediting requirements
  • Contributing guidelines
Updated 09/07/2017 18:58

implement go-ds-badger


I’m very excited about the badger datastore, it seems to be very optimized for a lot of the same things that ipfs needs.

When i first looked into it, the interfaces had no error handling, but now they have fixed that problem. I would like to get a badger datastore backend written so we can start testing how ipfs performs with it.

Updated 17/06/2017 22:56

Error writing block to datastore: Access is denied.


Version information:

go-ipfs version: 0.4.9- Repo version: 5 System version: amd64/windows Golang version: go1.8.1

Type: Bug

<!– One of following: Critical - System crash, application panic. High - The main functionality of the application does not work, API breakage, repo format breakage, etc. Medium - A non-essential functionality does not work, performance issues, etc. Low - An optional functionality does not work. Very Low - Translation or documentation mistake. Something that really does not matter much but should be noticed for a future release. –>

Severity: Medium


Started ipfs daemon: ipfs daemon Runs for a bit and connects to peers. Starts throwing errors in the console. [0;37m16:48:35.891 [31mERROR [0;34m bitswap: [0mError writing block to datastore: Access is denied. [0;37mbitswap.go:322[0m and [0;37m16:48:39.904 [31mERROR [0;34mcommands/h: [0merr: write tcp4> wsasend: An established connection was aborted by the software in your host machine. [0;37mhandler.go:288[0m

Updated 02/08/2017 09:20 7 Comments

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 07/08/2017 09:54 22 Comments

Extreme resource usage & hanging


Using IPFS master, d48cd56 Context: I have about 7 GB of pinned files, about ~100kb each. (The ipfs blocks directory is 18GB in size), migrated from IPFS 0.3 to 0.4.

ipfs cat of a short text file I added just before doesn’t seem to terminate after a few minutes of continuously reading ~400MB/s from an SSD where the IPFS blocks are stored.

I also noticed, that with smaller sized local ipfs block dirs (7 GB), freshly created on 0.4, ipfs cat does succeed, but after about ~5 seconds of full CPU usage. (it succeeds possibly because all the just added 7GB of data is cached in memory)

Seems like either a serious bug or a performance problem.

Question: Does IPFS use a trie for accessing/indexing hashes? If not, it definitely should.

Updated 11/07/2017 16:34 3 Comments

Fork me on GitHub