test/integration: don't listen on file descriptors.
make.go: unrelated, but options to make it much faster.
internal/images: t.Skip on HEIC dependency failures
Fixes#1140
Updates golang/go#25210
Change-Id: I8092155411826d6ed1f8d85230b753d1369044af
Unset CGO_ENABLED if no sign of gcc.
The localdisk renaming stuff was fixed in Go ages ago in
golang/go#13673 and https://golang.org/cl/6140
And a defer in storagetest meant Windows couldn't delete files
because a file was still open.
Change-Id: I57aef85f24653b19ce10e3d1e18c778cee2d48f6
My fault for not running the (slow) integration tests before I broke
things in a4d0cc6ab7.
Fixes#1136
Change-Id: Ia30051da02974d0c3e79e0b220ff86dcab5771e4
Just code movement.
Except I did delete some 5 year old localdisk migration code that's no
longer relevant.
Updates #1111 (this is prep for SFTP support)
Change-Id: Ibe1de1d4d804a6c86919a9df454ab125027e4c33
In f8bc4ac6e5 I made the root handler start returning 404s for
unknown URLs, which broke this test. Update this tests.
Fixes#1132
Change-Id: I6e14811dda00e741d80e1c5603f849ffcb26f361
And also speed up /importer/TYPE page's query by saying it's unsorted, which
gets us a better index. Hacky workaround. Should fix it in the query planner
later instead.
Fixes#1105
Change-Id: I140ffb40456ec802844584568d2f1a7a38b26e41
Still slow, but no more ffmpeg child processes, and I'm confident
ImageMagick will improve over time. There are actually ImageMagick
commits in the past few hours that look promising. We have a demo
tomorrow, so we're not going to bump our git rev & Docker image to the
latest ImageMagick master yet.
Updates #969
Change-Id: I7a8545821cae4214ea521d7cb46aa235ae3f0ed3
A bunch of mine had a larger initial ftyp box, which broke the second
part of the pattern. But the second part of the pattern doesn't matter
anyway. This only needs to casually recognize them. A later full
parse will determine what they really are.
This also adds some new debugging when CAMLI_DEBUG is true.
Change-Id: Ib4adc9b5447a64ba4682624e42b55f1d65779ef7
Even when AltLookupFun was defined, Lookup used to fallthrough after the
AltLookupFn, depending on what AltLookupFn returned.
This means in some cases, our tests in pkg/search did end up calling the
Google API (which was not intended). We found out because with the new
dependency on an API key for the Google service, we now rely on reading
the key from the config dir, which is wired to panic if it is accessed
during tests.
This change therefore simplifies Lookup, by making it return the results
of the AltLookupFn call, if AltLookupFn exists.
Change-Id: Ie196f892f36d309c725a6e869094364d49cffdc8
Since we don't support the latest MySQL version, our tests in Travis CI
are failing since they pull the latest docker image.
We should fix the issue
(https://github.com/perkeep/perkeep/issues/1114), but in the meantime,
we might as well restrict the tests to MySQL 5, so that CI tests keep on
being useful to alert us about other errors.
Change-Id: I32a2cc1dc5a4194c891183d96498dee14c759baf
If a GPS coordinate is bogus, we should have caught it when receiving
the blob, and not write it out as an index row.
If we did not, we end up catching it when trying to slurp it to the
corpus. At this point there's no reason to penalize the user by
panicking, we can instead skip it and log about the error.
Change-Id: Ie40479befca78d8b5da343ef1a8420f703f07cb7
For now, no user-visible changes.
But this will permit an SFTP blobstorage layer in the future.
Next step will be moving 90% of the code from the localdisk package
into the files package.
Updates #1111
Change-Id: I62b924e3d69ca47e7c0fa83c78a77808a71ea33e
We migrated to using the long form for key IDs sometime ago, but we
never updated the client of the gpgchallenge accordingly, so in
functions that take a keyID as an argument, it would fail to find the
given long keyID within a key ring.
However, for usability reasons, we want to keep the short form in the
hostname of the instance (and hence as the DNS entry), so we revert to
using the short form when perkeepd is setting its host name.
Change-Id: I8373016671fdead32780a04f6d64045e81cc9cd1
As make.go now does not install binaries in ./bin, but rather let them be
installed wherever go install does, the test World should now rely on
os/exec's LookPath to find the binaries it needs.
Fixes related failing tests
Change-Id: I256e79673ca994001e831aed9e7a3ab5ba485ead
Foursquare was rebranded Swarm (for check-ins) some time ago, so
rename our implementation to match the upstream branding. But still
store "foursquare" as the permanode importer type, to not break old
users. That override is now added to the new Properties struct, and
all importers now return their properties.
More stuff will be added to Properties later: WIP flag, bug link,
proper title, icon?
Change-Id: I31cbe2feec3dbf9c6bdb0c866056d9c6966313e3
We had checks in place to return an error if a search query had both
no constraint and no expression. However:
1) we accepted " " as a valid search expression (which is the
work-around that was used by the web UI for the index page)
2) the rest of the code seems to be coping well if we remove these
checks, which this CL does.
This allows us to remove the q=" " trick in the web UI, which does not
seem to be breaking anything, and has the side-effect of improving the
map aspect story (issue 1081). Because with this change, the index page
is not considered anymore as the result of a search query, which means
if one then clicks on an image, one then gets to the image permanode as
a "standalone" item, instead of as one item part of set.
As a consequence:
1) If one then clicks on the map aspect, one gets only this item on the
map (with the proper zoom level), instead of all the items from the
index page.
2) The other side of the coin is left/right navigation does not "work"
anymore in this context, since the item is not part of a set anymore.
In other words, this change makes the index page (i.e. the empty search)
a somewhat particular case, and makes it behave a little differently
from the result of any other (non-empty) search.
Updates issue #1081
Change-Id: Ibbb1711c67c7cf8adaf94ab5d2c68c3755e4983b
Also removed misc/buildbot while at it (which contained camput
references) since we don't use it anymore at all.
TODO: the OSX app seems to be relying on finding a binary in ../bin,
which we do not use anymore. This will probably need fixing.
Updates #981
Change-Id: I14220fbad2e81181330fca4bb2d2e5fe170e1bd6
A new "put" mode is added to the pk command, so that the "pk put"
command can be used to create and upload blobs.
What this command does is actually just call the previously named
"camput" executable, which is renamed to "pk-put" in this change.
This involves adding a new way to register a mode in cmdmain, when such
a mode is just meant to call an external binary. To emphasize the
distinction, the existing func (to register a sub-command, or a mode) is
renamed from RegisterCommand to RegisterMode, and RegisterCommand is now
the name of the new func/way.
Updates #981
Updates #1056
Change-Id: Ief954c17aa88a376f551df7de4b4e9fe41ad96d1
the changes to DecodeConfig in ce955adf48
moved the call to image.DecodeConfig to before the call to exif.Decode,
because we need to do that for the HEIF case.
After the call to exif.Decode, if err is nil and is not a short read
error, we ignore the error and the code goes on. To mark that intent,
we should have explicitly set the err to nil at this point. However,
that omission did not matter before
ce955adf48 because image.DecodeConfig
was the last setter of the error.
Now that it has moved up, we do have to explicitly reset the err to nil.
While we were at it, we rewrote the whole logic to be easier to read.
This seems to fix all the tests in pkg/index and pkg/search.
Change-Id: Id0b711179ccb1365b851d3e86ecb70d47ac358b4
Brad Fitzpatrick