When asked to install something, KNewStuff asks Attica for full information on download items, and that in turn asks the server for this information by calling the download/contentID/downloadID endpoint, which then returns the full information, and that's then passed up through Attica to KNewStuff, which then does the actual downloading and installing of the data. It looks like the content call and download call are a little out of sync somehow. Witness the two following bits of xml:
https://api.kde-look.org/ocs/v1/content/data/1298345 :
<downloadway1>1</downloadway1> <downloadtype1/> <downloadprice1>0</downloadprice1> <downloadlink1> https://dl.opendesktop.org/api/files/download/id/1557622663/s/bbe693c822c27f91ae530181a68a6c48/t/1557777346/o/1/com.github.vinceliuice.Qogir-dark.tar.xz </downloadlink1> <downloadname1>com.github.vinceliuice.Qogir-dark.tar.xz</downloadname1> <downloadsize1>642</downloadsize1> <downloadgpgfingerprint1/> <downloadgpgsignature1/> <downloadpackagename1/> <downloadrepository1/> <download_package_type1/> <download_package_arch1/> <downloadtags1>data##mimetype=application/x-xz</downloadtags1> <downloadway2>1</downloadway2> <downloadtype2/> <downloadprice2>0</downloadprice2> <downloadlink2> https://dl.opendesktop.org/api/files/download/id/1557725887/s/bbe693c822c27f91ae530181a68a6c48/t/1557777346/o/1/com.github.vinceliuice.Qogir.tar.xz </downloadlink2> <downloadname2>com.github.vinceliuice.Qogir.tar.xz</downloadname2> <downloadsize2>638</downloadsize2> <downloadgpgfingerprint2/> <downloadgpgsignature2/> <downloadpackagename2/> <downloadrepository2/> <download_package_type2/> <download_package_arch2/> <downloadtags2>data##mimetype=application/x-xz</downloadtags2> <downloadway3>1</downloadway3> <downloadtype3/> <downloadprice3>0</downloadprice3> <downloadlink3> https://dl.opendesktop.org/api/files/download/id/1557726051/s/bbe693c822c27f91ae530181a68a6c48/t/1557777346/o/1/com.github.vinceliuice.Qogir-light.tar.xz </downloadlink3> <downloadname3>com.github.vinceliuice.Qogir-light.tar.xz</downloadname3> <downloadsize3>635</downloadsize3> <downloadgpgfingerprint3/> <downloadgpgsignature3/> <downloadpackagename3/> <downloadrepository3/> <download_package_type3/> <download_package_arch3/> <downloadtags3>data##mimetype=application/x-xz</downloadtags3>
The above is the download sections of the content information for the Qogir theme. The following is the returned data for the call for full details on download item number 3, done like so:
https://api.kde-look.org/ocs/v1/content/download/1298345/3 :
<ocs> <meta> <status>ok</status> <statuscode>100</statuscode> <message/> </meta> <data> <content details="download"> <downloadway>1</downloadway> <downloadlink> https://dl.opendesktop.org/api/files/download/id/1557725887/s/24d108864611fcb7f6b301d8b364923b/t/1557779801/o/1/com.github.vinceliuice.Qogir.tar.xz </downloadlink> <mimetype>application/x-xz</mimetype> <gpgfingerprint/> <gpgsignature/> <packagename/> <repository/> <download_package_type/> <download_package_arch/> <downloadtags/> </content> </data> </ocs>
As you can see there, this is actually the information for download item 2 (and the inverse happens when calling for information on item 2, which then has the data for item 3). So much as i don't like to defer blame, i'm afraid this is a server side issue. (luckily, really, too, in that fixing it there will then of course also fix it for everybody else without having to wait for the next Frameworks release ;) )