"RegistryKeyLookupFailed" about imageview.jl

[timholy]

This is actually an error in Images, not ImageView. But we can have the conversation here.

There's some problem with your installation of ImageMagick. I may have to ask @ihnorton or @tkelman to chime in, unfortunately (sorry!).

[tkelman]

I avoid touching the registry whenever possible, and am not familiar with how the BinDeps are set up for ImageMagick. Does Pkg.build("Images") work?

[joa-quim]

No, it fails with

...
INFO: Done downloading file https://julialang.s3.amazonaws.com/bin/winnt/extras/innounp.exe
INFO: Changing Directory to C:\j\.julia\v0.3\Images\deps\downloads
The setup files are corrupted or made by incompatible version. Maybe it's not an Inno Setup installation at all.
(0047C56A)
===============================[ ERROR: Images ]================================


failed process: Process(`innounp.exe -q -y -b -e -x '-dC:\j\.julia\v0.3\Images\deps\usr\lib\x64' ImageMagick-6.9.0-0-Q16-x64-dll.exe`, ProcessExited(1)) [1]
while loading C:\j\.julia\v0.3\Images\deps\build.jl, in expression starting on line 76

===============================================================================

[joa-quim]

OK, We've been here before. The file
http://www.imagemagick.org/download/binaries/ImageMagick-6.9.0-0-Q16-x64-dll.exe
that it tries to download does not exist anymore and I get an empty ImageMagick-6.9.0-0-Q16-x64-dll.exe

[tkelman]

Looks like you need another instance of JuliaImages/Images.jl@bc409e3? Care to submit a PR over at Images.jl?

[tkelman]

On second thought I'll do it, and suggest enabling AppVeyor too. With the scheduled nightly runs like @timholy has enabled for HDF5, it should make finding out about and fixing upstream binary problems more quickly.

[joa-quim]

Ah, that was why I was lost trying to find where to change the version number.
But now I'm stuck in that messy situation where Pkg does not advance nor let me remove a broken package. Neither Pkg.update() updates nor Pkg.remove() removes

julia> Pkg.rm("Images")
INFO: No packages to install, update or remove
INFO: Package database updated

[tkelman]

Right, it is horrendously underdocumented that when you do Pkg.rm it actually moves the package to Pkg.dir(".trash"), and by default restores packages from there before cloning a new fresh copy. I'm not entirely sure why that's the default behavior, and there's at least one issue open to add a stronger version of Pkg.rm that will permanently delete things instead of moving them around to .trash.

[joa-quim]

Hmm, I'm actually now getting

julia> Pkg.rm("Images")
INFO: Removing Images (unregistered)
ERROR: unlink: operation not permitted (EPERM)
 in unlink at fs.jl:97 (repeats 2 times)

and in .trash there is only a 0 bytes 'Images' file

[tkelman]

Maybe it is trying to delete something there instead of move it to .trash, but it's something that's locked by some other process. Try running an unlocker tool, or restarting all Julia instances.

[joa-quim]

I don't understand. I made a fork of Images.jl but I now see in Images.jl/deps/build.jl is totally different from the timholy/Images.jl. Meanwhile I applied the change in my local copy but went directly to version 7.0 and got this error

INFO: Changing Directory to C:\j\.julia\v0.3\Images\deps\downloads; Version detected: 5500 (Unicode)
===============================[ ERROR: Images ]================================


Provider BuildProcess failed to satisfy dependency libwand
while loading C:\j\.julia\v0.3\Images\deps\build.jl, in expression starting on line 76

going back to 6.9.0-3 solved the issue and Pkg.build("Images") run till the end.
So a warning about an likely trouble with ImageMagick 7.0

[tkelman]

Good to know, I also went with 6.9.0-3 for JuliaImages/Images.jl#242 since there were both 32 and 64 bit binaries available, 7.0 only had 64 bit binaries that I could see.

[tkelman]

I don't understand. I made a fork of Images.jl but I now see in Images.jl/deps/build.jl is totally different from the timholy/Images.jl.

That would be because your fork https://github.com/joa-quim/Images.jl is just many commits behind. It would be nice if there were some automatic hosted "update my forks for me" service somewhere.

[joa-quim]

But how come that happened? I did the fork just now. Shouldn't it have 'copied' the current Images.jl?
... or had I done another fork a while before and it's showing me it now!

[tkelman]

Judging by the February commit dates, I'd guess you forked the repository in February? If you try to click fork again when you have already created a fork, it won't update anything.

[joa-quim]

Yes, I clicked again. How do one solve such situations? Do I have to kill the fork and start over again?

[tkelman]

Or go to the command-line, add this repository and your fork as different remotes, pull from this remote and push to your fork.

[joa-quim]

Ah, thanks. The pull the trigger solution seams much simpler.

[tkelman]

Would be nice if GitHub could figure out a way to implement more features from the command line in the web UI. They will try to sell you on their GitHub for Windows / GitHub for Mac GUI apps, but they're both pretty lousy IMO. Some of my colleagues like Sourcetree which looks much more powerful and still fairly easy to use.

[timholy]

Looks like this can be closed, given JuliaImages/Images.jl@3603852. Feel free to reopen if that's incorrect.