Created attachment 123239 [details] screenshot of error message SUMMARY Critical: could not load fallback mirror list from QUrl STEPS TO REPRODUCE 1. try to install via kdewin-installer-gui-1.1.0.exe 2. get the error 3. profit OBSERVED RESULT error message EXPECTED RESULT installation SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Created attachment 123240 [details] log file
Created attachment 123241 [details] log file log file
Windows 7 Sp1 x64 no antivirus no firewall
This installer has been unmaintained and dysfunctional for years, where did you get it from? Use the application's stand-alone windows installer (if available) instead.
http://ftp.surfnet.nl/windowing/kde/Attic/kdewin/installer/kdewin-installer-gui-1.1.0.exe
We use it in ReactOS for tests. And it used to work before https://download.kde.org/stable/kdewin/installer/kdewin-installer-gui-1.1.0.exe also same result
That installer has been deprecated and unmaintained for an incredibly long period of time i'm afraid - if it had worked up until now that was due to sheer chance. Please note that the /stable/ URL is a compatibility redirect to the /Attic/ equivalent, as the file was removed from /stable/ long ago.
Could we perhaps remove these binaries from our servers? We can keep the matching sources.
Historically we've taken the position that artifacts once published shouldn't be removed from download.kde.org (as in the future it may no longer be possible to compile that code). Software that should no longer be used is archived in the Attic/ though, which denotes that it is out of date and intended for archival purposes only.
Perhaps we should reconsider this, given that old stuff like that contains numerous security issues in the normal case.
The same could be said to apply to all the old releases which have outstanding security issues in them even though you'd need to compile them to get something executable - in which case most of the Attic should be removed.
There you can argue that you still need to compile it on your own. The other stuff is easily runnable by any average joe user.
I agree that we keep it somewhere as rebuilding it will prove to be hard. Keeping links alive makes sense for sources but not for binaries I think. So I suggest to break the links. While Attic sounds funny, I would prefer something more like WARNING_THIS_IS_VERY_OLD_SOFTWARE_DONT_EXPECT_IT_TO_WORK ....
But could you just fix the URLs in kdewin-installer-gui-1.x.0.exe Because we extremely NEED it for tests in ReactOS. ReactOS is alpha so security issues are security issues not a question. The question to have one-two-three click installer. Please-please, I am begging you, make a new fixed version of kdewin-installer-gui-1.x.0.exe and do not move it anymore ^)
>That installer has been deprecated and unmaintained somebody still maintains this https://github.com/KDE/kdewin-installer/ but he does not provide a binary
Can't you find something better to test than software that doesn't even work on the original Windows?
>Can't you find something better to test than software that doesn't even work on the original Windows? One we started and have been doing it for a long time, we can't stop it. Come on, guys, is it really that hard to fix just one URL in kdewin-installer-gui-1.x.0.exe?
We broke it on purpose. And won't fix it. Its open source so feel free to maintain it yourself. If you do pls make sure not to point windows users to a ages old unsupported software.
Then why do you host https://download.kde.org/stable/kdewin/installer/kdewin-installer-gui-1.1.0.exe ??? WTF
I still think we should just delete that. It doesn't work anymore. People theoretically could rebuild it with the sources, but even if not, it has no valid use-case, or?
It has a valid use-case for legacy platforms in semi-isolated environments (lan with proxy or NAT + firewall).
and in virtual machines of course
The URL has now been changed to clearly indicate that the installer is unsupported. This also has the effect of breaking the /stable/ URLs which had previously remained working (due to special code dedicated to keeping old links alive)
Created attachment 123470 [details] kdewin-installer-gui-1.4.0.exe Here is an update of the installer
(In reply to Sven Brauch from comment #4) > Use the application's stand-alone windows installer (if available) instead. There are about 85 applications not available as release version. Compare https://binary-factory.kde.org/search/?q=release_win64 with https://community.kde.org/Windows/Releases/4.10.2 Also I do not think that the approach of single installers is a good idea to provide the whole KDE experiences because of space requirements. Release 4.10.2 provides 104 applications, where the base libraries requires about 580MB and each app only a few MB. In the opposite a single app from binary factory requires about 840 MB. du -hs kmahjongg-master-13-windows-msvc2017_64-cl 843M kmahjongg-master-13-windows-msvc2017_64-cl Another app shows du -hs kmymoney-5.0-370-windows-msvc2017_64-cl 332M kmymoney-5.0-370-windows-msvc2017_64-cl Taking the mean value 580 MB per app would require about 60 GB to install all 104 apps, not counting the single update nightmare.
We currently aim to provide quality over quantity. The applications we now provide have a Windows maintainer of some kind. In KDE 4 days we published everything as long as it compiled, no matter whether it was usable or not. Most people won't be interested in installing all KDE applications so we don't specialize on that scenario. Kmahjongg is a bad example as it was just recently added to binary factory and the installer isn't optimised yet.
I do not know where you get your numbers, but I think they are inaccurate. The KDevelop installer is less than 150 MB, and KDevelop is a *huge* application, packing essentially all KDE frameworks, all Qt libraries including QtWebkit, and several of the large clang frontend libraries. A simple application using Qt and 2-3 frameworks should have an installer sizes of certainly less than 20 MB. My private 17kloc project using KArchive has an installer with 13 MB, shipping KArchive, most of QtWidgets, QtNetwork, Qwt, zlib, several data files, and of course the application itself. The unpacked size is 32 MB on-disk, and that is 64-bit-code already. As for what is the right way to do it, this installer is not what people using the Windows platform expect, and the stuff it ships is outdated and unmaintained. Most of it was never maintained in the first place.
Could we let the installer rest? The KDE 4.x stuff is "totally" unmaintained. Even more on Windows then on Unices. I remember well the bug reports I had for Kate, that varied from "Can't save a file" to "Crash everywhere". I really don't think we should provide this anymore and lurk people to dark places with non-working software that damage our reputation... Why do I now spend days of my spare time to have a better experience for the KF5 based stuff if people still can grab easily by accident the old broken stuff?
(In reply to Sven Brauch from comment #27) > I do not know where you get your numbers, I wrote that I used du -hs to get the size of the directory where the binary was unpackaged. > but I think they are inaccurate. No > The KDevelop installer is less than 150 MB, You are refering to the installer size where I'm talking about unpackaged size, which is required on the local disc. > and KDevelop is a *huge* application, packing essentially all KDE frameworks, > all Qt libraries including QtWebkit, and several of the large clang frontend > libraries. See the following kdevelop example: 1. download https://binary-factory.kde.org/job/KDevelop_Release_win64/lastSuccessfulBuild/artifact/kdevelop-5.4.3-617-windows-msvc2017_64-cl.7z 2. unpack this archive for example into kdevelop-5.4.3-617-windows-msvc2017_64-cl 3. run du -hs kdevelop-5.4.3-617-windows-msvc2017_64-cl which returns: 802M kdevelop-5.4.3-617-windows-msvc2017_64-cl or use Explorer on Windows to open properties of the mentioned directory, which returns for the size on disc: 799MB
Which is not the files which are contained in or installed by the installer. This for example contains lots of debug information a hundred megabytes of translations for all languages in the world, as well as several megabytes of X11 cursors, 156 MB spellchecker dicts for all languages, all breeze icons twice (once as resource, once as icons), QtTest.dll, a GNU info page for gpg, ... you get the point. This is in no way representative of what you would actually ship.
> Here is an update of the installer May I kindly ask you to upload the new binary to https://github.com/KDE/kdewin-installer/releases/tag/v1.4.0 as well So we can reuse it for ReactOS RAPPS
Ralf Habacker
Actually, comparing file sizes is not important. Yes, the new installers are larger, in most parts due to spellcheckers/translations + e.g. icons. The important part is: they are kind of maintained. The nice 4.10.2 release from X years ago has security flaws like https://kde.org/info/security/advisory-20190807-1.txt (and that is just one inside our libs, not counting the stuff we bundled there) If you use e.g. Kate with the built-in file browser from that version, you might just get hi-jacked just by browsing e.g. your Downloads folder... I really think we shall not make it easy to install that stuff.
I just wanted to add stuff to the installer to redirect users to binary-factory in case a related release version is available in favor to provide the old version. On testing this new stuff I recognized that the related directories seems to be changed in a way that they are no more accessable: https://download.kde.org/Attic/4.10.2/win32/ Forbidden You don't have permission to access this resource. Apache/2.4.29 (Ubuntu) Server at download.kde.org Port 443 https://download.kde.org/Attic/kdewin/ Forbidden You don't have permission to access this resource. Apache/2.4.29 (Ubuntu) Server at download.kde.org Port 443
(In reply to Sven Brauch from comment #30) for the record: > Which is not the files which are contained in or installed by the installer. I downloaded https://binary-factory.kde.org/job/KDevelop_Release_win64/lastSuccessfulBuild/artifact/kdevelop-5.4.3-617-windows-msvc2017_64-cl.exe and started the installer, which says that it need 789MB of disc space. > This for example contains lots of debug information No, debug informations are located in a different package, see filename *-dbg.7z at https://binary-factory.kde.org/job/KDevelop_Release_win64/ As Christoph pointed out, this is not a problem at the moment, but it will be when users install a lot of KDE applications and wonder where the disk space has gone.
(In reply to Ralf Habacker from comment #35) > (In reply to Sven Brauch from comment #30) > for the record: > > Which is not the files which are contained in or installed by the installer. > I downloaded > https://binary-factory.kde.org/job/KDevelop_Release_win64/ > lastSuccessfulBuild/artifact/kdevelop-5.4.3-617-windows-msvc2017_64-cl.exe > and started the installer, which says that it need 789MB of disc space. > > > This for example contains lots of debug information > No, debug informations are located in a different package, see filename > *-dbg.7z at https://binary-factory.kde.org/job/KDevelop_Release_win64/ > > As Christoph pointed out, this is not a problem at the moment, but it will > be when users install a lot of KDE applications and wonder where the disk > space has gone. https://phabricator.kde.org/D12283 Would already save about 100mb of disk space per installation. The issue was the ram usage increased drastically. But overall compressed dict's would be great. We still use the blacklist approach and for many paackages we install too many icons etc. For example we use .rcc's for icon themes, and the uncompressed icons aren't used at all, still many packages don't blacklist them. So it depends on the maintainer to improve the installation size.
If we're using RCC's for icons, couldn't we just globally blacklist individual icon files for all packages?
We could try to blacklist the breeze/.../... icon theme folders. To blacklist all icons has the issue that some applications might install own ones that are not in the themes we ship as rccs (if I am not wrong).
(In reply to Christoph Cullmann from comment #38) > We could try to blacklist the breeze/.../... icon theme folders. > > To blacklist all icons has the issue that some applications might install > own ones that are not in the themes we ship as rccs (if I am not wrong). In Kate I already added bin/data/icons/.* but its hard to tell what other apps do. It should be fine for most packages.