Bug 249980

I can confirm the same problem on Kubuntu Lucid with KDE 4.5.1.  It's happened with every script I've tried.

I should add, as a workaround, if the plasma package is manually downloaded and manually unzipped to some directory, "plasmapkg -i directory/" works correctly, so I suspect something is going wrong with the decompression.

this works here, but it sounds like you may have kdelibs built without zip support?

(i tried the exact plasmoid package the original report used, btw :)

Ok, I will file this with arch linux then, and see if we can get it fixed. Is there a way to know if kdelibs have zip support?

Is there anything required for adding zip support (dependenciý on zup/unzip or such)?

I still believe that plasma should report the failure, instead of pretending that the install went well.

There are other bugreports about install failures that are not reported to the user, so this can stay closed. (at least i'm almost sure that there are other bugs open like that).

Oh yeah, it's a Kubuntu packaging problem. I agree that it happens here on Kubuntu with KDE 4.5.1, but:
I've tried and the same is reproducable on OpenSUSE and PCLinuxOS with KDE 4.5.1

So please reopen this bug.

Whoops, I meant "packaging problem", not "Kubuntu packaging problem".

This has been seen by users on Fedora packages, I checked our kdelibs build logs and there's nothing reported missing by CMake (other than ASpell and HSpell which we don't build against because we use Enchant with Hunspell, but this is not related to ZIP support in any way).

Yep, I run Fedora13/4.5.1 and can only install plasmoids using the workaround in Comment #2

"This has been seen by users on Fedora packages"

great, so describe a method to reproduce the issue using specific, detailed, reproducable steps.

i grabbed the tasktimer.plasmoid file from kde-look.org and ran: plasmapkg -i <number->tasktimer.plasmoid and it installed. after a few moments (the time it takes kbuilsycoca4 to run) it showed up in ksycoca.

so i can't reproduce it from trunk doing the normal steps one would expect. so its one of: there are differences between what i'm doing and what others are doing, there's a difference in how the software is built, there's a difference in system configuration.

without being able to reproduce, there's nothing i can do.

it could be KTempDir returning an unwritable directory (though that would lead to "No metadata file in package" being output. perhaps the call to KArchive::copyTo results in unreadable files (similar to doing a `chdmod u-r`), so it gets written, can be stated (avoiding "No metadata file in package") but can't be read.

do some digging, but i know this at least works on a reasonable system.

I'm having the same problem, and several people at arch are reporting it as well: https://bbs.archlinux.org/viewtopic.php?id=104060

Dear Aaron, what makes a system qualify as "reasonable"?

And what exactly is required to build kdelibs with zip support? Is there a library or package requirement, or a cmake switch, or is it autodetected? and if so, is there a warning if it is not found? With this information, I could make a request to the kdelibs packager in my potentially not reasonable system.

@Joel Schaerer: unfortunately there is no useful information there in terms of clues that can help identify where the problem is. we really need people looking into what is causing the failure for people.

@Anders Lund: 'what makes a system qualify as "reasonable"?'

in this case: one with a working KZip, one where KTempDir results in a writable directory, one where KArchive::copyTo results in files that are readable by the same user the application is running as.

"what exactly is required to build kdelibs with zip support?"

according to kdelibs/CMakeLists.txt:

find_package(ZLIB)
macro_log_feature(ZLIB_FOUND "ZLib" "The Zlib compression library" "http://www.zlib.net" TRUE "" "Required by the core KDE libraries and some critical kioslaves.")

"is there a warning if it is not found?"

yes, as can be seen above.

The Fedora packages definitely have zlib support enabled, as evidenced by the build logs.

"The Fedora packages definitely have zlib support enabled, as evidenced by the
build logs."

great; can you check the other possible causes i listed?

(why does this feel like pulling hen's teeth? as a fair warning: unless someone puts some real effort into tracking this down, i will eventual de-prioritize the report in my queue.)

libkdecore as well as kio_archieve links against zlib here, and all files in /tmp/kde-anders/ as well as the directory itself are owned and read/writable by me, including for example while browsing zip archieves using kio.

I tried to figure this out tonight with gdb, I'm sorry I'm not so great at debugging but here's what I observed:

 - The errors are being thrown out during the call to Plasma::PackageStructurePrivate::createPackageMetadata
 - I set a breakpoint there and watched my temporary directory
 - The temporary folder is created, and the contents of the .plasmoid zip file are copied there.
 - Interestingly, the directory structure of the plasmoid file is correctly extracted, but the files themselves are full of binary garbage which the "file" command cannot identify.
 - Thus, the PackageMetadata constructor cannot make sense of the files and throws the errors.

I'll keep poking at this, but I figured more experienced minds might be able to make better sense of my observations.  Looks to me like KZip might be the problem?  My Ark works fine on zip packages, dunno if that means anything though.

"but the files themselves are full of binary garbage"

that would certainly explain it.

"Looks to me like KZip might be the problem?"

yes, or the library beneath it (zlib) thought that's unlikely or the class "above" it (KArchive; a couple of bug fixes just went into KArchive, but afaik that was only to fix regressions in trunk and the problems addressed never made it into a release?)

"My Ark works fine on zip packages"

there are a couple of Ark plugins that provide zip support, and it seems that the clizip one (which doesn't use KZip) is the one with the highest priority.

just checked and ark isn't even building the karchive based plugin these days. so it's not using the same code path at all.

if you have a source checkout, then you can turn this on by editting kdeutils/ark/plugins/karchiveplugin/CMakeLists.txt to have "add_subdirectory(karchiveplugin)" instead of "add_subdirectory( clizipplugin )"

you will also need to remove `kde4-config --prefix`/share/kde4/services/kerfuffle_clizip.desktop manually and run kbuildsycoca4.

Instead of messing with Ark, I wrote short script in Python / PyKDE to extract archives the same way PackageStructure::metadata() does it, namely:
 - Create a KZip object from a plasmoid or arbitrary zip file
 - Create a KArchiveDirectory using KZip.directory()
 - Use KArchiveDirectory::copyTo to extract the contents to a folder

The results on my system exhibited the same problem: directory structure was right, but the files were all full of garbage.  It was the same whether I extracted an archive with one file or a complex directory structure, and whether or not I used a temporary directory created by KTempDir or just a regular directory in my ~. 

I looked over KZip and KArchive sources, but I don't understand enough about file decompression to know what I'm looking for.  Do we need to refile this bug against KDElibs?

This is not a plasma bug, this is a bug in the extraction routine of the  KZip library. I've tried to extract some files form a zipped file and all i can get is garbage:

const KArchiveFile* epsFile=static_cast<const KArchiveFile*>(epsEntry);
            QString dir=KGlobal::dirs()->saveLocation("tmp", "eps-tmp/");
            epsFile->copyTo(dir);

 Im using kde 4.5.1 shipped from kubuntu 10.04 32 bits.

Same problem on gentoo, built from source via portage.

Additionally I noticed following message in logs

plasma-desktop(2052)/knewstuff (api) KNS3::Cache::readRegistry: The file  "/home/mg/.kde4/share/apps/knewstuff3/plasmoids.knsregistry"  could not be opened.

but I think it's because no plasmoid was successfully installed before.

*** Bug 251304 has been marked as a duplicate of this bug. ***

Ok, I did a small test with three different clean devel accounts. I am using Arch Linux 64 bit with kdemod.

In two cases I checked out kdelibs and kdeplasma-addons from 4.5 branch and then compiled it with release and in the other with debug mode. In both cases installing comics -- also uses plasmapkg -- did work.

In the last case I installed kdelibs 4.5.1 tag and then kdeplasma-addons from 4.5 branch and compiled it in release mode. This time it did _not_ work.

So I suppose this problem is fixed now, whatever it was initially.

seems that the bug dfaure fixed in libkio trunk also did affect branch. at least it's resolved. good news.

It would be great if someone could reproduce what I did i.e. trying with 4.5 branch. Or even better track the commit down that fixed it, that way what caused the problem would be clear, at least in retrospect.

Reopended it by accident.

*** Bug 252612 has been marked as a duplicate of this bug. ***