Can't install plugins in Arch Linux's community sigil package

[DiapDealer]

Originally Posted by KevinH

I am confused? What does Linux builds of Sigil use to replace minizip? Is it a perhaps a newer version of minizip or do they actually patch Sigil in some way to use a different unzipping tool?

I don't think they're patching anything zip-related. I'm just thinking that Sigil (and they're certainly not using Sigil's included minizip source when building) is being built against different versions of repo-supplied minzip libraries.

I'll be honest ... I'm grasping at straws here. I have no idea why the default compression program on a linux system would have any bearing on how (or if) Sigil unzips a plugin file for installation. I just know that on a custom-built Sigil, its unzipping ability (minzip) is typically linked right into the Sigil executable itself, instead of passing it off to separate system libs.

[roger64]

Hi

I had a look: file-roller is already installed on my system. I do not use engrampa.

[eschwartz]

And I use engrampa and not file-roller, and it works fine. Since they both rely on libarchive or zip/unzip, and Sigil works fine without either one installed, I cannot imagine why it would matter anyway.
The presence or absence of unrelated software should have zero effect on Sigil.

Sigil just uses the system libminizip.so, and no patches whatsoever are applied (except sigil-git patches the shellscript launcher to add the SIGIL_DICTIONARIES environment variable), just USE_SYSTEM_LIBS=1

[KevinH]

Wow - that is strange. I am out of ideas.

roger64, if you click on the button that takes to you your preferences folder and look in plugins does the DOCXImport folder exist? If so, what files are inside that directory?

There is one other trick you can try:

Exit completely from Sigil.
Then manually go to your Sigil Preferences directory and into the plugins directory and manually copy the zip there and manually unzip DOCXImport_v0.1.0.zip into its own folder. Look inside to make sure you can see the plugin.xml and the plugin.py files at the very least.

Then fire up Sigil. Is the plugin detected? Does it work?

KevinH

[Doitsu]

Originally Posted by eschwartz

And I use engrampa and not file-roller, and it works fine.

When you directly open a downloaded plugin.zip file with engrampa, do you also see the non-existing home folder shown in my first screenshot?

BTW, I'm creating my own build following DiapDealer's instructions, i.e. it's quite possible that you don't experience any plugin unpacking problems despite having engrampa installed, because your build might reference different system libraries.

[eschwartz]

I sure do. I see a /home/eschwartz/DOCXImport_v0.1.0.zip file inside the zip, actually. Or else, wherever the DOCXImport_v0.1.0.zip file is located.

But I think that may be a bug in engrampa.

[Doitsu]

Originally Posted by eschwartz

I sure do. I see a /home/eschwartz/DOCXImport_v0.1.0.zip file inside the zip, actually. Or else, wherever the DOCXImport_v0.1.0.zip file is located.

But I think that may be a bug in engrampa.

If engrampa sees a non-existing home folder most likely the Sigil plugin import code also sees it and'll report an error since valid Sigil plugins may only contain one folder.

Since Arch Linux is a rolling distro it's highly likely that a system update broke something that makes engrampa and presumable some other programs like Sigil see a non-existing home folder.
I.e., this problem will most likely disappear on its own after one of the next system updates. (On my machine it disappeared after I re-installed the latest file-roller version.)

As KevinH has suggested, as a work-around, Arch Linux users affected by this issue should simply manually extract plugin zip archives to ~/.local/sigil-ebook/sigil/plugins.

[eschwartz]

I did say I thought it was an engrampa bug.

And sure enough, when I investigated, I found the bug:
Upstream file-roller bug
Engrampa bug report
Engrampa fix

...

Uninstall p7zip and Engrampa works properly. It is flagged out-of-date and presumably a fixed version of Engrampa will appear in Arch soon.

Regardless, since Sigil does not parse the stdout of `7za l` in order to figure out how to extract a plugin using minizip, it is completely irrelevant what Engrampa does and the Engrampa bug is merely a fun coincidence doubling as a red herring.

[DiapDealer]

@roger64:

More on the "Not a valid Sigil plugin" error message you get when using sigil package from the Arch community repo: I set up a brand-new Arch system and got a Cinnamon Desktop going. Just a bare-bones GUI install. After installing the sigil package, I get the exact same error you do! However... after removing the sigil package and installing sigil-git from the AUR, everything works as it should. If I remove sigil-git and reinstall the sigil package, I'm right back to the same, "Not a valid Sigil plugin" error message when attempting to install a plugin.

So it's my opinion that something is simply wrong with the Arch sigil package. Use sigil-git from the AUR instead (or build Sigil manually).

@Doitsu: I know you managed to get the same error with a custom Sigil build by removing/install different packages, but I have to assume you're somehow exposing some other deficiency by doing that.

Weird stuff.

[roger64]

Originally Posted by DiapDealer

@roger64:

More on the "Not a valid Sigil plugin" error message you get when using sigil package from the Arch community repo: I set up a brand-new Arch system and got a Cinnamon Desktop going. Just a bare-bones GUI install. After installing the sigil package, I get the exact same error you do! However... after removing the sigil package and installing sigil-git from the AUR, everything works as it should. If I remove sigil-git and reinstall the sigil package, I'm right back to the same, "Not a valid Sigil plugin" error message when attempting to install a plugin.

So it's my opinion that something is simply wrong with the Arch sigil package. Use sigil-git from the AUR instead (or build Sigil manually).

Thanks for your great help (to you and all the Sigil team)! It's clear now. I will perform a horse change.

[eschwartz]

Well, I wish I actually knew what my sigil-git package is doing right.

Weird stuff.

[DiapDealer]

I broke this conversation out into its own thread since it seemed clear that it had nothing to do with my DOCXImport plugin (itself or it's zipfile). Hope no one minds. Just trying to clean up the plugin's thread a bit.

[roger64]

One remark about this ArchLinux zip question, if it may give a clue - or not.

1. - With Linux Mint (Cinnamon), I can chose the menu entry "extract here" with any EPUB file, without having to rename it as a zip, and it breaks down in a folder with OEBPS FILES. Handy.

2. With ArchLinux (Cinnamon), if I try to do the same, I face a refusal

Impossible d'ouvrir this.epub
Type d'archive non pris en charge

and if I wish to to break it down, I need to rename it first as a zip.

I have no idea how to explain this difference.

Sorry if this comment is not relevant...

[Doitsu]

Originally Posted by roger64

2. With ArchLinux (Cinnamon), if I try to do the same, I face a refusal

I had the same problem on my arch machine. file-roller refused to unpack .ePub files, but engrampa did.

[DiapDealer]

I noticed the same thing. Somebody mentioned Ark on KDE had the same problem. Seems like some archive utilities read the mimetype file (or assume a mimetype from the extension) and try to find a matching plugin instead of simply treating it like a zip archive.

EDIT: for what it's worth, I just use xarchiver on systems where the default archive manager seems to not want to deal with epubs.