On Wed, Jan 1, 2020 at 4:39 AM Thomas Friedrichsmeier <thomas.friedrichsme...@ruhr-uni-bochum.de> wrote: > > On Tue, 31 Dec 2019 13:29:19 +0000 > Hannah von Reth <han...@von-reth.de> wrote: > > > Well, dependenciesgui (and dependencies.exe) are not working for me > > > either, right now. Will try to figure out that one, later, AFK for a > > > while, now. > > > > Oh yes they are shims to dev-util/dependencies/... > > > > Pls try invoking then directly. > > In the next days I try a win8. > > I had already figured that much, however dependenciesgui.exe still > failed, silently, and dependencies.exe claimed not to find ClrPhl.dll > (or what it was called), even though that was in the same directory. > > Anyway: Success of sorts. Seeing that the kshimgen blueprint does not > actually build from source, I just tried forcing it to download that > win32-version, instead. And TA-DA! that works. (I.e. produces working > shims; note that the system *is* 64bit). > > So now I just had to trick it into bootstrapping with that, and now I'm > happily building packages (at least for the moment).
Out of curiosity Thomas, what in particular are you packaging? I only ask because i've noticed that the stable Kdenlive installer we distribute on download.kde.org isn't signed by us, which means it isn't produced by the Binary Factory (yet a substantial number of the files within it are, meaning they come from our cache). Is there any reason for rebuilding Kdenlive yourself? > > Long story short: Whatever the cause of the problem, it does not affect > the 32-bit build of kshimgen. > > Regards > Thomas Cheers, Ben
