<div dir="ltr"><div dir="ltr">On Sat, Jan 18, 2020 at 9:50 AM Inoki Shaw <<a href="mailto:veyx.shaw@gmail.com">veyx.shaw@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">Hi Aleix,</div></div></blockquote><div><br></div><div>Hi Inoki,</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div>Sure! It must be a good idea.<div dir="auto"><br></div><div dir="auto">But the fact is that, in the app bundle packed by craft automatically, there are still some dependencies with wrong relative path(rpath). It will lead a failed notarization of the bundle, which will cause an error like "cannot open the application of an unidentified developer", when user tries to open it.</div><div dir="auto">I'm still working on a solution to fix the rpath during craft packing step, there is a small patch on phabricator but I find it doesn't work well.</div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div dir="auto"><br></div><div dir="auto">That version on my GitHub is an outdated version, on which I fixed manually the rpath of dependencies.</div></div></div></blockquote><div><br></div><div>Okay. Ideally we'd have all of this stuff able to happen automatically so fixing those rpath issues is probably the most important thing at this stage.</div><div><br></div><div>The Binary Factory is now performing signing of everything it produces, although it isn't yet notarizing things (although that is something which I believe is being worked on).</div><div>This has already showed up some issues with MacOS packaging which also will need fixing.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div dir="auto"></div></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div dir="auto"><br></div><div dir="auto">I'm happy to see one on the website. I can manually fix the rpath, notarize it and publish it on the right place this weekend.</div><div dir="auto"><br></div><div dir="auto">PS: I noticed recently the nightly build fails 😅 btw I'll try to fix as soon as possible.</div><div dir="auto"><br></div>Inoki<br></div></div></blockquote><div><br></div><div>Cheers,</div><div>Ben</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 17, 2020, 17:12 Aleix Pol <<a href="mailto:aleixpol@kde.org" target="_blank">aleixpol@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Inoki,<br>
We've been looking with Ben into ways of getting KDE software builds<br>
for mac, since other KDE components were looking into it too. This has<br>
put KDE Connect in a weird position where all KDE macOS binaries would<br>
be in KDE except for KDE Connect which is in your github.<br>
<br>
I was wondering if we could move kde connect macos builds into<br>
<a href="http://binary-factory.kde.org" rel="noreferrer noreferrer" target="_blank">binary-factory.kde.org</a> so we can serve them with the rest. What do you<br>
think, Inoki?<br>
<br>
Aleix<br>
</blockquote></div></div></div>
</blockquote></div></div>