Gitlab (commit) notifications
Hi! Is there any self-service way to receive commit/push notifications via email from gitlab? If so, would such notifications include work-branches (that would be useful, IMO)? Regards Thomas pgpX1NfO91Ni3.pgp Description: Digitale Signatur von OpenPGP
Re: Gitlab (commit) notifications
Am Thu, 21 May 2020 20:16:22 +1200 schrieb Ben Cooksley : > On Thu, May 21, 2020 at 12:20 AM Thomas Friedrichsmeier > wrote: [...] > > Is there any self-service way to receive commit/push notifications > > via email from gitlab? > > > > If so, would such notifications include work-branches (that would be > > useful, IMO)? > > Work branches cannot be notified on, as otherwise you end up > renotifying all of the new commits in that work branch every time you > force push. > (It is impossible for hooks to tell if you are pushing a rewritten > commit or a new one) Ok, I can live with that (I don't intend to make use of force-pushing, anyway, and may just switch to a different prefix, where appropriate). However, I'd certainly welcome a feature to have commit notifications on non-"work" branches (without merge requests). In RKWard we used to have commit notifications going to a dedicated mailing list (rkward-tracker) that also receives build failure notifications and such, for a single point to subscribe to "all the noise" for the project. IIRC, that notification mechanism was set up for us by sysadmin, not by self-service. Not exactly a high-priority thing, but I for one would welcome this feature. Regards Thomas pgpiK7e2DtQq4.pgp Description: Digitale Signatur von OpenPGP
kdemail.net as sender address
Hi! In addition to @kde.org mailboxes for core developers and KDE e.V. members, KDE.org offers @kdemail.net-aliases for contributors. This is quite neat in allowing to keep a stable - and dedicated - contact address for contributions across KDE. As such it is great for use in copyright headers and as git commit email. However, what about discussion related to contributions? I for one would love to use an @kdemail.net address for KDE-related mails both on public mailing lists and in private exchange. Admittedly, getting contacted about a message written months or years in the past is a rare (but possible) exception, so a stable address may not be super important in this context. However, it would still offer the comfort of separating project-related mail from e.g. family or work related mail. It would also "look nice" in giving KDE contributors an immediately visible standing when talking to external parties (distributions / library maintainers / users). According to a quick survey of my local mail archives, such use of @kdemail.net seems to have been _somewhat_ common for a while, but seems to be essentially nonexistent after about 2017. The reason for that, I *assume* could be that it has become increasingly difficult to use @kdemail.net as a sender address. Many mail providers will refuse to even let you send from a different address, and many (receiving) mail providers will look upon a mail received from a non-SPF-sanctioned server with suspicion. A quick and ridiculously non-representative test among three mail providers suggests that only one out of three will allow me to use thomas.friedrichsme...@kdemail.net as a sender address for a test email, and of the two others, one will classify the mail as SPAM upon receiving it (without giving human readable reasons). Long story short: How would you (sysadmin, in particular) feel about the following: 1) Create an SPF-record specifying mail.kde.org as the legitimate sender of @kdemail.net mails. 2) Allow and encourage contributors to send @kdemail.net-mails via mail.kde.org. This would still be for sending, only. Incoming mail would continue to be forwarded to some external mailbox. -- Disclaimer: As you may have guessed, I'm currently in the process of replacing my primary mail provider/address, and looking for a decent long-term solution, personally. Regards Thomas pgpfpbnRYq5bX.pgp Description: Digitale Signatur von OpenPGP
Re: kdemail.net as sender address
Hi Ben! Am Sat, 19 Sep 2020 22:58:35 +1200 schrieb Ben Cooksley : > On Sat, Sep 19, 2020 at 7:57 PM Thomas Friedrichsmeier < > thomas.friedrichsme...@gmx.de> wrote: [...] > > Long story short: How would you (sysadmin, in particular) feel about > > the following: > > 1) Create an SPF-record specifying mail.kde.org as the legitimate > > sender of @kdemail.net mails. > > > > Not sure how this got missed, but it has now been done. > I've also setup DKIM verification at the same time. Great! > > 2) Allow and encourage contributors to send @kdemail.net-mails via > > mail.kde.org. This would still be for sending, only. Incoming mail > > would continue to be forwarded to some external mailbox. > > > > This is already permitted, however the community member in question > needs to apply to Sysadmin to be granted permissions to send email > via Letterbox. Previously we had granted this automatically to all > Developers and members of the KDE e.V., however this had to be > changed following issues we had with people's Identity accounts being > compromised and used to send spam. That's fine and good to know. I added some clarifications to https://community.kde.org/Infrastructure/Email, and will look into a merge request for the kdemail.net website, later. Thanks! Thomas pgpyTLLLVAP2k.pgp Description: Digitale Signatur von OpenPGP
Re: kdemail.net as sender address
Am Sun, 20 Sep 2020 07:06:09 +1200 schrieb Ben Cooksley : > On Sun, Sep 20, 2020 at 12:00 AM Thomas Friedrichsmeier < > thomas.friedrichsme...@gmx.de> wrote: > > That's fine and good to know. I added some clarifications to > > https://community.kde.org/Infrastructure/Email, and will look into a > > merge request for the kdemail.net website, later. > > > > It might be worth just redirecting the whole kdemail.net website to > that page, as it essentially covers what is needed. > Thoughts? Sounds reasonable to me. I guess the key idea is that somebody seeing a kdemail.net-address should have a straightforward way to find out what that domain is all about. No need to duplicate the info. Thomas
Re: Proposal: make squash-merging the default behavior for gitlab MRs
Am Tue, 6 Oct 2020 08:26:02 -0600 schrieb Nate Graham : > GitLab already *kind of* offers this, in the form of the "Squash > commits" checkbox next to the merge button. Apparently it's not > obvious enough though, because I can think of a bunch of cases of > multi-commit MRs with mostly garbage commits accidentally not being > squashed when merging. Unfortunately the workflow is rather backwards in that the checkbox needs to be ticked, when creating the merge request, not after review. However right before merging would be the time to judge whether the commit history contains valuable information or useless noise. (IIRC the "squash commits" checkbox can still be changed at that point, but it's not obviously visible, then). Probably not something we can easily configure/adjust downstream, though? Thomas pgp9MX2Jti8Wu.pgp Description: Digitale Signatur von OpenPGP
How do you deal with incomplete commits?
Hi all, may I pick your brains for this question that keeps coming up for me? Say I'm working on a feature in branch A. I have some changes in my working copy that are so half-baked that I don't want them to end up in the commit history as such, but I don't want to throw them away, either. Now I want to switch to branch B for something unrelated. What do I do with my changes? How do you folks deal with this? 1) Stash my changes, then switch. Works, but the stash is something that I tend to forget about, when going back, and this method get messy, quickly, when dealing with several branches at once. 2) Commit the changes, anyway, but marked as "WIP" or similar, and use commit --amend, when coming back. However, it wouldn't be the first time that I forgot to amend, after all, and pushed my WIP-commits. 2a) I could use a "work/" branch, which would at least give me a chance to correct this after pushing. I'd still have to remember to do so, before merging my work into a regular branch, though. 2b) What I'd really like to see is a commit keyword that would make git throw an error, if I try to commit something on top of it, thus forcing me to use commit --amend. 2c) Alternatively, do we have a keyword that would prevent a commit from being pushed (or from being merged to something that is not a "work/" branch)? That would not be as nice as 2b, IMO, but it would still catch my usual mistakes. Any other solution that I am missing? Do we have something along the lines of 2c (not according to our docs, AFAICS)? Regards Thomas pgpHC43D2M7sF.pgp Description: Digitale Signatur von OpenPGP
Re: How do you deal with incomplete commits?
Hi, thanks for your answer (also to Nate). But to clarify, my question is really: How do I _force_ myself to clean up in time? Am Sat, 31 Oct 2020 15:44:35 +0100 schrieb Thomas Baumgart : > On Samstag, 31. Oktober 2020 13:39:04 CET Thomas Friedrichsmeier > wrote: [...] > > Say I'm working on a feature in branch A. I have some changes in my > > working copy that are so half-baked that I don't want them to end > > up in the commit history as such, but I don't want to throw them > > away, either. > > I assume, you don't thing about pushing those at all. Right, I do not intend to push those, but I'm afraid, I might (esp. in case I'm returning to my work days, weeks or even months, later). So I'm looking for a way to stop myself from doing so. Thomas pgpYXFleXij8C.pgp Description: Digitale Signatur von OpenPGP
Re: How do you deal with incomplete commits?
Hi, Am Sat, 31 Oct 2020 16:38:09 +0100 schrieb Thomas Baumgart : > Reading your question over and over, I don't see where git is > mentioned :) This leads to a short answer: self-discipline. > > My impression is that you look for a some magic feature in git that > forces you to clean up in time. Not sure if something like that > exists. fair enough. And yes, I am looking for some magic feature in git. If that doesn't yet exist, then how about adding a hook (server-side) that will reject any commit containing "NOPUSH" (or whatever) in the commit message, though? Of course, if I'm the only one to be this sloppy, I'll have to resort to the knots-in-the-handkerchief-method, after all... Thomas pgpLnbKIjzqud.pgp Description: Digitale Signatur von OpenPGP
Re: How do you deal with incomplete commits?
Am Sat, 31 Oct 2020 17:09:22 +0100 schrieb David Hurka : > Maybe you could write your own commit hook, which prevents commiting > anything when `git log --oneline` matches, say /\A INCOMPLETE/x. Hm, true, it doesn't have to be a server-side hook. Thanks for pointing me in the right direction. Thomas pgpzsSvcguO9R.pgp Description: Digitale Signatur von OpenPGP
Re: How do you deal with incomplete commits?
Am Sun, 01 Nov 2020 09:52:27 -0800 schrieb Thiago Macieira : > On Saturday, 31 October 2020 08:25:40 PST Thomas Friedrichsmeier > wrote: > > thanks for your answer (also to Nate). But to clarify, my question > > is really: How do I _force_ myself to clean up in time? > > If you're pushing to a code review system of any kind, it doesn't > matter. First, you should always review what you've sent for review > anyway and you can notice you pushed something incomplete. At that > point don't create the review request or write that it isn't yet > ready for review. > > Second, your reviewers should notice it's incomplete and won't > approve. Well, the context that I'm worrying about, here, is one where reviews are not mandatory and not the norm. I ended up writing a local pre-commit hook, which has the advantage of triggering on the commit directly after "the problem commit", thus increasing the likelihood there is still a trivial way to sort things out. (For good measure I also activated the pre-push hook as mentioned by Nicolas.) Thomas pgpyYsBFzYQzr.pgp Description: Digitale Signatur von OpenPGP
Re: How do you deal with incomplete commits?
Am Mon, 02 Nov 2020 17:51:29 + schrieb David Jarvie : > On Monday 02 Nov 2020 18:39:52 Thomas Friedrichsmeier wrote: > > I ended up writing a local pre-commit hook, which has the advantage > > of triggering on the commit directly after "the problem commit", > > thus increasing the likelihood there is still a trivial way to sort > > things out. > > Would you mind sharing the hook which you wrote? I've had the same > dilemma as you, and your hook seems a good solution. Sure: https://invent.kde.org/-/snippets/1341 Regards Thomas pgpdEefD6jOA0.pgp Description: Digitale Signatur von OpenPGP
Re: New cmake warning.
On Tue, 3 May 2022 10:35:20 +0200 Méven wrote: > I am guessing you are using cmake >= 3.16 so it allows you to run, but > since the project does not have a cmake minimum, for others using > cmake < 3.16 the build will break. > This warning highlights it, so you inform your contributor they need > cmake 3.16 before running into the hard fail in FindKF5. On the downside, project wishing to remain backwards-compatible with older systems (which will come with older versions of both cmake and ECM) will want to avoid adding such a requirement, explicitly. Thomas pgpA1enz4BbdQ.pgp Description: OpenPGP digital signature
Debugging CI test failures
Hi! Would anybody have a hint for me on how to diagnose an issue in running tests on the gitlab (Windows) CI? My newly added test fails with an exception: https://invent.kde.org/education/rkward/-/jobs/354885 Test project C:/builds/education/rkward/_build Start 1: rkward-core_test 1/1 Test #1: rkward-core_test .Exit code 0xc135 ***Exception: 0.23 sec 0% tests passed, 1 tests failed out of 1 0xc135 appears to be STATUS_DLL_NOT_FOUND, but which one (and why)? The test works inside my craft environment (and in the freebsd and linux CIs). Thanks for any pointers! Thomas pgp7GnqAFMy6H.pgp Description: OpenPGP digital signature
Re: Debugging CI test failures
On Sun, 12 Jun 2022 20:48:59 +1200 Ben Cooksley wrote: > On Sun, Jun 12, 2022 at 6:13 PM Thomas Friedrichsmeier < > thomas.friedrichsme...@kdemail.net> wrote: [...] > > https://invent.kde.org/education/rkward/-/jobs/354885 > > > > Test project C:/builds/education/rkward/_build > > Start 1: rkward-core_test > > 1/1 Test #1: rkward-core_test .Exit code 0xc135 > > ***Exception: 0.23 sec > > 0% tests passed, 1 tests failed out of 1 > > > > 0xc135 appears to be STATUS_DLL_NOT_FOUND, but which one (and > > why)? > > Rather strange, the CI system does it's best to setup PATH such that > Windows should be able to find all the necessary DLLs. > > Are you able to confirm what libraries the rkward-core test links > against? As core_test.exe is not included in the CI artifact, only indirectly. In theory it should be the same as those used for rkward.exe + Qt5Test.dll. (The theory holds true in my craft environemnt, although, notably that is a MinGW-build, so the list itself is different, there). rkward.exe taken from the CI artifact links against: Qt5WebEngineWidgets.dll Qt5WebEngineCore.dll KF5KIOFileWidgets.dll KF5TextEditor.dll Qt5Qml.dll KF5Parts.dll KF5XmlGui.dll Qt5PrintSupport.dll KF5KIOWidgets.dll KF5ConfigWidgets.dll KF5KIOCore.dll KF5Crash.dll KF5WindowSystem.dll Qt5Network.dll KF5JobWidgets.dll Qt5DBus.dll KF5Service.dll KF5I18n.dll KF5CoreAddons.dll KF5Completion.dll KF5WidgetsAddons.dll Qt5Widgets.dll Qt5Xml.dll KF5ConfigCore.dll Qt5Gui.dll KF5Archive.dll Qt5Core.dll VCRUNTIME140_1.dll (This list has the same dlls as the known good rkward.exe built on binary-factory, only the order is different.) At runtime a fairly large number of additional dlls are loaded, as listed by tasklist /m (attached). I case you are wondering: No R dlls are involved, because those are used in a separate process, only. Can you make anything out of that? Thomas Libararies loaded at runtime by rkward.exe on Windows 8.1 ntdll.dll, KERNEL32.DLL, KERNELBASE.dll, Qt5WebEngineWidgets.dll, Qt5WebEngineCore.dll, KF5KIOFileWidgets.dll, KF5TextEditor.dll, Qt5Qml.dll, KF5Parts.dll, KF5XmlGui.dll, Qt5PrintSupport.dll, KF5KIOWidgets.dll, KF5ConfigWidgets.dll, KF5KIOCore.dll, KF5Crash.dll, KF5WindowSystem.dll, Qt5Network.dll, KF5JobWidgets.dll, Qt5DBus.dll, KF5Service.dll, KF5I18n.dll, KF5CoreAddons.dll, KF5Completion.dll, KF5WidgetsAddons.dll, Qt5Widgets.dll, Qt5Xml.dll, KF5ConfigCore.dll, Qt5Gui.dll, KF5Archive.dll, Qt5Core.dll, USER32.dll, MSVCP140.dll, VCRUNTIME140.dll, VCRUNTIME140_1.dll, api-ms-win-crt-string-l1-1-0.dll, api-ms-win-crt-runtime-l1-1-0.dll, api-ms-win-crt-environment-l1-1-0.dll, api-ms-win-crt-stdio-l1-1-0.dll, api-ms-win-crt-math-l1-1-0.dll, api-ms-win-crt-heap-l1-1-0.dll, api-ms-win-crt-locale-l1-1-0.dll, SHELL32.dll, Qt5Quick.dll, Qt5QuickWidgets.dll, Qt5WebChannel.dll, Qt5Positioning.dll, COMDLG32.dll, dbghelp.dll, GDI32.dll, OLEAUT32.dll, SHLWAPI.dll, VERSION.dll, WINMM.dll, WINSPOOL.DRV, WS2_32.dll, USERENV.dll, CRYPT32.dll, IPHLPAPI.DLL, ncrypt.dll, Secur32.dll, WINHTTP.dll, d3d11.dll, dxgi.dll, dwmapi.dll, DWrite.dll, WTSAPI32.dll, d3d9.dll, dxva2.dll, COMCTL32.dll, HID.DLL, api-ms-win-crt-convert-l1-1-0.dll, api-ms-win-crt-filesystem-l1-1-0.dll, api-ms-win-crt-utility-l1-1-0.dll, api-ms-win-crt-time-l1-1-0.dll, USP10.dll, dhcpcsvc.DLL, urlmon.dll, KF5Bookmarks.dll, KF5Solid.dll, KF5IconThemes.dll, KF5KIOGui.dll, KF5ItemViews.dll, KF5GuiAddons.dll, KF5Codecs.dll, KF5ConfigGui.dll, KF5SyntaxHighlighting.dll, editorconfig.dll, KF5TextWidgets.dll, KF5SonnetUi.dll, KF5SonnetCore.dll, DNSAPI.dll, zlib1.dll, ADVAPI32.dll, libssl-1_1-x64.dll, libcrypto-1_1-x64.dll, ole32.dll, KF5DBusAddons.dll, intl-8.dll, NETAPI32.dll, UxTheme.dll, MSVCP140_1.dll, libpng16.dll, harfbuzz.dll, libbzip2.dll, liblzma.dll, zstd.dll, MPR.dll, icuin67.dll, icuuc67.dll, pcre2-16.dll, msvcrt.dll, combase.dll, Qt5QmlModels.dll, ucrtbase.DLL, RPCRT4.dll, WINMMBASE.dll, NSI.dll, profapi.dll, MSASN1.dll, WINNSI.DLL, bcrypt.dll, NTASN1.dll, sechost.dll, iertutil.dll, WININET.dll, SETUPAPI.dll, Qt5Svg.dll, pcre2-8.dll, Qt5TextToSpeech.dll, iconv.dll, netutils.dll, srvcli.dll, wkscli.dll, icudt67.dll, cfgmgr32.dll, DEVOBJ.dll, SSPICLI.DLL, LOGONCLI.DLL, CRYPTBASE.DLL, SHCORE.DLL, bcryptPrimitives.dll, SAMCLI.DLL, IMM32.DLL, MSCTF.dll, qwindows.dll, freetype.dll, kernel.appcore.dll, powrprof.dll, opengl32.dll, GLU32.dll, DDRAW.dll, DCIMAN32.dll, libEGL.DLL, libGLESv2.dll, dcomp.dll, d3d10warp.dll, qwindowsvistastyle.dll, breeze.dll, breezecommon5.dll, dbus-1-3.dll, api-ms-win-crt-multibyte-l1-1-0.dll, mswsock.dll, fwpuclnt.dll, rasadhlp.dll, qgif.dll, qico.dll, qjpeg.dll, jpeg62.dll, qpdf.dll, Qt5Pdf.dll, qsvg.dll, KIconEnginePlugin.dll, CRYPTSP.dll, rsaenh.dll, sonnet_ispellchecker.dll, clbcatq.dll, MsSpellCheckingFacility.dll, Bcp47Langs.dll, Normaliz.dll, actxprxy.dll, kateprojectplugin.dll, KF5NewStuff
Re: Debugging CI test failures
On Tue, 14 Jun 2022 23:16:04 +1200 Ben Cooksley wrote: > On Mon, Jun 13, 2022 at 7:56 AM Thomas Friedrichsmeier < > thomas.friedrichsme...@kdemail.net> wrote: > > > On Sun, 12 Jun 2022 20:48:59 +1200 > > Ben Cooksley wrote: > > > > > On Sun, Jun 12, 2022 at 6:13 PM Thomas Friedrichsmeier < > > > thomas.friedrichsme...@kdemail.net> wrote: > > [...] > > > > https://invent.kde.org/education/rkward/-/jobs/354885 > > > > > > > > Test project C:/builds/education/rkward/_build > > > > Start 1: rkward-core_test > > > > 1/1 Test #1: rkward-core_test .Exit code > > > > 0xc135 ***Exception: 0.23 sec > > > > 0% tests passed, 1 tests failed out of 1 > > > > > > > > 0xc135 appears to be STATUS_DLL_NOT_FOUND, but which one > > > > (and why)? > > > > > > Rather strange, the CI system does it's best to setup PATH such > > > that Windows should be able to find all the necessary DLLs. > > > > > > Are you able to confirm what libraries the rkward-core test links > > > against? [...] > Thanks for all of these details. > > Is there a way for us to find out whether it successfully completes > initial startup and then fails when completing the later loading? > It seems that 0xc135 errors tend to be related .Net - which is > included in that extract you attached. Sorry for my lousy turn around time. Not sure, if I can provide a definite answer, but I have added a qDebug()-statement as the very first thing in initTestCase(). I learned that on the other CIs, when a test fails, the debug output is shown. In this case, nothing gets shown at all, and that seems to point to a very early problem, indeed - assuming nothing unrelated keeps debug messages from showing, here. Another thing I have tried is to avoid calling into QWebEngine while setting up the testcase, as that's certainly my first guess on what might be causing trouble. This did not change, anything, however. I suppose, I could try seting up some dummy test binaries, linking against the various libraries, hoping to narrow down the problem that way? Regards Thomas pgpXNpViakJ2S.pgp Description: OpenPGP digital signature
Re: Debugging CI test failures
On Wed, 15 Jun 2022 17:51:52 +0200 Thomas Friedrichsmeier wrote: [...] > I suppose, I could try seting up some dummy test binaries, linking > against the various libraries, hoping to narrow down the problem that > way? Ok, that finally led to something. I have no idea, why this is happening, or how to fix it, but I have isolated QWebEngine as the troublemaker. relevant portion of CMakeLists.txt: add_executable(linktest linktest.cpp) target_link_libraries(linktest PRIVATE Qt5::Test Qt5::WebEngineWidgets) add_test(NAME rkward-linktest COMMAND linktest) ecm_mark_as_test(linktest) relevant code: https://invent.kde.org/education/rkward/-/blob/work/diagnose_testfailure/rkward/autotests/linktest.cpp result: https://invent.kde.org/education/rkward/-/jobs/359945 (2/2 Test #2: rkward-linktest ..Exit code 0xc135) Note that "new QWebEngineView();" does not even have to be called. It's enough that the line of code is present, directly or indirectly. In contrast - for instance - creating a KTextEditor::Document/View does not cause any trouble. (In case you are wondering: That branch is a toy branch with only the Windows CI enabled, and intended to be deleted. Feel free to use it for further testing, should that help.) Regards Thomas pgpAzwGdjiK8y.pgp Description: OpenPGP digital signature
Re: Debugging CI test failures
On Thu, 16 Jun 2022 22:26:31 +1200 Ben Cooksley wrote: > On Thu, Jun 16, 2022 at 8:08 AM Thomas Friedrichsmeier < > thomas.friedrichsme...@kdemail.net> wrote: > > > On Wed, 15 Jun 2022 17:51:52 +0200 > > Thomas Friedrichsmeier wrote: > > [...] > > > I suppose, I could try seting up some dummy test binaries, linking > > > against the various libraries, hoping to narrow down the problem > > > that way? > > > > Ok, that finally led to something. I have no idea, why this is > > happening, or how to fix it, but I have isolated QWebEngine as the > > troublemaker. > > > > relevant portion of CMakeLists.txt: > > > > add_executable(linktest linktest.cpp) > > target_link_libraries(linktest PRIVATE Qt5::Test > > Qt5::WebEngineWidgets) add_test(NAME rkward-linktest COMMAND > > linktest) ecm_mark_as_test(linktest) > > > > relevant code: > > > > https://invent.kde.org/education/rkward/-/blob/work/diagnose_testfailure/rkward/autotests/linktest.cpp > > > > result: > > https://invent.kde.org/education/rkward/-/jobs/359945 > > > > (2/2 Test #2: rkward-linktest ..Exit code > > 0xc135) > > > > Note that "new QWebEngineView();" does not even have to be called. > > It's enough that the line of code is present, directly or > > indirectly. In contrast - for instance - creating a > > KTextEditor::Document/View does not cause any trouble. > > > > Interesting. When you build RKward on your local system do you use the > Craft cache or does your system build everything itself? > I wonder if the Craft binaries for WebEngineWidgets are broken - and > MSVC doesn't check down the full chain when it does it's linking. Well, my local craft builds are MinGW-based, and so are using QWebKit, instead. So that does not really compare. No problem, there, however, despite using the cache. I did just check that the latest MSVC build from binary-factory is working. Of course that doesn't contain the test, but rkward itself works fine. I'm currently trying to get my MSVC craft root back to life, but that seems to take another while... Regards Thomas pgpqt1z2xtjTb.pgp Description: OpenPGP digital signature
Re: Debugging CI test failures
On Thu, 16 Jun 2022 17:31:16 +0200 Thomas Friedrichsmeier wrote: > On Thu, 16 Jun 2022 22:26:31 +1200 > Ben Cooksley wrote: > > > On Thu, Jun 16, 2022 at 8:08 AM Thomas Friedrichsmeier < > > thomas.friedrichsme...@kdemail.net> wrote: > > > > > On Wed, 15 Jun 2022 17:51:52 +0200 > > > Thomas Friedrichsmeier wrote: > > > [...] > > > > I suppose, I could try seting up some dummy test binaries, > > > > linking against the various libraries, hoping to narrow down > > > > the problem that way? > > > > > > Ok, that finally led to something. I have no idea, why this is > > > happening, or how to fix it, but I have isolated QWebEngine as the > > > troublemaker. > > > > > > relevant portion of CMakeLists.txt: > > > > > > add_executable(linktest linktest.cpp) > > > target_link_libraries(linktest PRIVATE Qt5::Test > > > Qt5::WebEngineWidgets) add_test(NAME rkward-linktest COMMAND > > > linktest) ecm_mark_as_test(linktest) > > > > > > relevant code: > > > > > > https://invent.kde.org/education/rkward/-/blob/work/diagnose_testfailure/rkward/autotests/linktest.cpp > > > > > > result: > > > https://invent.kde.org/education/rkward/-/jobs/359945 > > > > > > (2/2 Test #2: rkward-linktest ..Exit code > > > 0xc135) > > > > > > Note that "new QWebEngineView();" does not even have to be called. > > > It's enough that the line of code is present, directly or > > > indirectly. In contrast - for instance - creating a > > > KTextEditor::Document/View does not cause any trouble. > > > > > > > Interesting. When you build RKward on your local system do you use > > the Craft cache or does your system build everything itself? > > I wonder if the Craft binaries for WebEngineWidgets are broken - and > > MSVC doesn't check down the full chain when it does it's linking. > > Well, my local craft builds are MinGW-based, and so are using QWebKit, > instead. So that does not really compare. No problem, there, however, > despite using the cache. > > I did just check that the latest MSVC build from binary-factory is > working. Of course that doesn't contain the test, but rkward itself > works fine. > > I'm currently trying to get my MSVC craft root back to life, but that > seems to take another while... Ok, so no problem (well not _that_ problem, anyway) on craft MSVC 2019 with Craft cache. That's a Windows 8.1 VM by the way. Thomas pgp3MRFaj0OZ3.pgp Description: OpenPGP digital signature
Re: Debugging CI test failures
On Sat, 18 Jun 2022 21:50:33 +1200
Ben Cooksley wrote:
> On Fri, Jun 17, 2022 at 8:04 AM Thomas Friedrichsmeier <
> thomas.friedrichsme...@kdemail.net> wrote:
>
> > On Thu, 16 Jun 2022 17:31:16 +0200
> > Thomas Friedrichsmeier wrote:
> >
> > > On Thu, 16 Jun 2022 22:26:31 +1200
> > > Ben Cooksley wrote:
> > >
> > > > On Thu, Jun 16, 2022 at 8:08 AM Thomas Friedrichsmeier <
> > > > thomas.friedrichsme...@kdemail.net> wrote:
> > > >
> > > > > On Wed, 15 Jun 2022 17:51:52 +0200
> > > > > Thomas Friedrichsmeier
> > > > > wrote: [...]
> > > > > > I suppose, I could try seting up some dummy test binaries,
> > > > > > linking against the various libraries, hoping to narrow down
> > > > > > the problem that way?
> > > > >
> > > > > Ok, that finally led to something. I have no idea, why this is
> > > > > happening, or how to fix it, but I have isolated QWebEngine
> > > > > as the troublemaker.
> > > > >
> > > > > relevant portion of CMakeLists.txt:
> > > > >
> > > > > add_executable(linktest linktest.cpp)
> > > > > target_link_libraries(linktest PRIVATE Qt5::Test
> > > > > Qt5::WebEngineWidgets) add_test(NAME rkward-linktest COMMAND
> > > > > linktest) ecm_mark_as_test(linktest)
> > > > >
> > > > > relevant code:
> > > > >
> > > > >
> > https://invent.kde.org/education/rkward/-/blob/work/diagnose_testfailure/rkward/autotests/linktest.cpp
> >
> > > > >
> > > > > result:
> > > > > https://invent.kde.org/education/rkward/-/jobs/359945
> > > > >
> > > > > (2/2 Test #2: rkward-linktest ..Exit code
> > > > > 0xc135)
> > > > >
> > > > > Note that "new QWebEngineView();" does not even have to be
> > > > > called. It's enough that the line of code is present,
> > > > > directly or indirectly. In contrast - for instance - creating
> > > > > a KTextEditor::Document/View does not cause any trouble.
> > > > >
> > > >
> > > > Interesting. When you build RKward on your local system do you
> > > > use the Craft cache or does your system build everything itself?
> > > > I wonder if the Craft binaries for WebEngineWidgets are broken
> > > > - and MSVC doesn't check down the full chain when it does it's
> > > > linking.
> > >
> > > Well, my local craft builds are MinGW-based, and so are using
> > > QWebKit, instead. So that does not really compare. No problem,
> > > there, however, despite using the cache.
> > >
> > > I did just check that the latest MSVC build from binary-factory is
> > > working. Of course that doesn't contain the test, but rkward
> > > itself works fine.
> > >
> > > I'm currently trying to get my MSVC craft root back to life, but
> > > that seems to take another while...
> >
> > Ok, so no problem (well not _that_ problem, anyway) on craft MSVC
> > 2019 with Craft cache. That's a Windows 8.1 VM by the way.
> >
>
> Strange. Just curious - do we see any additional library dependencies
> in WebEngineWidgets that aren't present in the other Qt libraries?
There may be more elegant ways to find this info (I'm definitely not up
to speed on Windows tools), but: I started rkward, listed the loaded
dlls using "tasklist /m", then did the same for kate, and compared the
lists. Most, but not all, differences should be related to QWebEngine
("+" means only in rkward.exe, "-" is only in kate.exe). Surprisingly,
this also includes some differences in filename case, for whatever
reason.
+ AVRT.dll
+ cfgmgr32.dll
- CFGMGR32.dll
+ d3d10warp.dll
+ d3dcompiler_47.dll
+ dbghelp.dll
+ DCIMAN32.dll
+ dcomp.dll
+ DDRAW.dll
+ dhcpcsvc6.DLL
+ dhcpcsvc.DLL
+ DWrite.dll
- dwrite.dll
+ dxva2.dll
- externaltoolsplugin.dll
+ GLU32.dll
+ HID.DLL
+ iertutil.dll
- katefiletreeplugin.dll
+ katesnippetsplugin.dll
+ KF5Bookmarks.dll
+ KF5KIOFileWidgets.dll
- KUserFeedbackCore.dll
- KUserFeedbackWidgets.dll
+ libEGL.DLL
+ libGLESv2.dll
+ MFCaptureEngine.dll
+ mf.dll
+ mfh264enc.dll
+ mfplat.dll
+ mfreadwrite.dll
+ MMDevApi.dll
+ mscms.dll
+ msmpeg2vdec.dll
+ msvproc.dll
+ ncrypt.dll
+ NLAapi.dll
+ NTASN1.dll
+ ntmarta.dll
+ opengl32.dll
+ Qt5Positioning.dll
+ Qt5QuickWidgets.dll
+ Qt5WebChannel.dll
+ Qt5WebE
Re: Debugging CI test failures
On Sun, 19 Jun 2022 00:44:08 +1200 Ben Cooksley wrote: [...] > Looks like DirectX and it's corresponding components are missing: > > PS C:\> Get-ChildItem -Path C:\ -Recurse -ErrorAction SilentlyContinue > -Force -Filter ddraw.dll > PS C:\> Get-ChildItem -Path C:\ -Recurse -ErrorAction SilentlyContinue > -Force -Filter glu32.dll > PS C:\> Get-ChildItem -Path C:\ -Recurse -ErrorAction SilentlyContinue > -Force -Filter MFCaptureEngine.dll > > Looks like to make QtWebEngine work we would need to make some > changes to our Windows image: > - > https://social.msdn.microsoft.com/Forums/en-US/b646b841-c9fb-4f39-9662-5b59f02279ab/installing-servermediafoundation-in-a-docker-container?forum=windowscontainers > - > https://social.msdn.microsoft.com/Forums/lync/en-US/386adbc4-3e43-4896-8cbb-ba9cc7fc6b72/how-to-install-directx-to-windows-server-core-docker-container?forum=windowscontainers That looks like a bit of a mess, too. What is your (and everybody's) take on how we should proceed? Are those changes to the image more trouble than it's worth? I still have the alternative option to factor out any linkage to QWebEngine from the testcase. Annoying but possible. (Is there a way to detect that it's a CI build?) Regards Thomas pgpeZAKOsgsod.pgp Description: OpenPGP digital signature
Re: Debugging CI test failures
On Sun, 19 Jun 2022 22:43:54 +1200 Ben Cooksley wrote: [...] > We therefore have no choice but to address this as annoying as it is. > > Would you like to start this process off with a MR to > https://invent.kde.org/sysadmin/ci-images/-/blob/master/windows-msvc2019/Dockerfile > ? Can do, but I won't be fast. Regards Thomas pgpDhA6B02IZG.pgp Description: OpenPGP digital signature
Re: Debugging CI test failures
On Wed, 22 Jun 2022 22:49:42 +1200 Ben Cooksley wrote: > On Mon, Jun 20, 2022 at 9:12 AM Thomas Friedrichsmeier < > thomas.friedrichsme...@kdemail.net> wrote: > > > On Sun, 19 Jun 2022 22:43:54 +1200 > > Ben Cooksley wrote: > > [...] > > > We therefore have no choice but to address this as annoying as it > > > is. > > > > > > Would you like to start this process off with a MR to > > > > > https://invent.kde.org/sysadmin/ci-images/-/blob/master/windows-msvc2019/Dockerfile > > > > > ? > > > > Can do, but I won't be fast. > > > > I've had a stab at doing this now in > https://invent.kde.org/sysadmin/ci-images/-/jobs/366231 Ah, great! (My own efforts did not even get as far as building a local docker image for testing. Unsurprisingly, that didn't work on a Linux host, but also didn't work in a Windows VM, and not on a Windows 10 thumb drive, either, so I had had to postpone that project.) Regards Thomas > Note that if this succeeds we'll need to check it worked - and if it > did then we can proceed to rebuilding windows-qt515 which should > hopefully fix our issues :) > > > > Regards > > Thomas > > > > Cheers, > Ben pgp13cVCveqTF.pgp Description: OpenPGP digital signature
Re: Debugging CI test failures
On Fri, 24 Jun 2022 16:22:08 +1200 Ben Cooksley wrote: > On Thu, Jun 23, 2022 at 8:36 PM Ben Cooksley > wrote: > > > On Wed, Jun 22, 2022 at 11:41 PM Thomas Friedrichsmeier < > > thomas.friedrichsme...@kdemail.net> wrote: > > > >> On Wed, 22 Jun 2022 22:49:42 +1200 > >> Ben Cooksley wrote: > >> > On Mon, Jun 20, 2022 at 9:12 AM Thomas Friedrichsmeier < > >> > thomas.friedrichsme...@kdemail.net> wrote: > >> > > >> > > On Sun, 19 Jun 2022 22:43:54 +1200 > >> > > Ben Cooksley wrote: > >> > > [...] > >> > > > We therefore have no choice but to address this as annoying > >> > > > as it is. > >> > > > > >> > > > Would you like to start this process off with a MR to > >> > > > > >> > > > >> https://invent.kde.org/sysadmin/ci-images/-/blob/master/windows-msvc2019/Dockerfile > >> > >> > > > >> > > > ? > >> > > > >> > > Can do, but I won't be fast. > >> > > > >> > > >> > I've had a stab at doing this now in > >> > https://invent.kde.org/sysadmin/ci-images/-/jobs/366231 > >> > >> Ah, great! > >> > >> (My own efforts did not even get as far as building a local docker > >> image for testing. Unsurprisingly, that didn't work on a Linux > >> host, but also didn't work in a Windows VM, and not on a Windows > >> 10 thumb drive, either, so I had had to postpone that project.) > >> > > > > You will need a Windows 11 or Windows Server 2022 system in order > > to build our Docker images. > > > > Due to limitations in Windows 10 and earlier versions of Windows > > Server the Docker image and Host versions of Windows had to be > > precisely synchronised. > > With recent updates to Windows 10 at least, there is no longer a > > compatible image available so it is no longer a viable option as a > > container host. > > > > (We are running Windows Server 2022 on the CI nodes, as it makes > > installation of Docker that actually functions properly > > straightforward - unlike on Desktop where it is very flaky, at > > least on Windows 10) > > I've now completed rebasing our image on top of a full Windows Server > Docker image (rather than the Server Core image used previously). > Initial checks indicate that the image does contain the previously > identified missing libraries so hopefully that resolves the issue. Thanks! Should I expect to see this on gitlab CI, already? (Test is still failing with the same exception, there, but perhaps you simply haven't rolled out the image, yet). Regards Thomas pgp9vrpNYUppr.pgp Description: OpenPGP digital signature
Re: Debugging CI test failures
On Sat, 25 Jun 2022 08:55:16 +1200 Ben Cooksley wrote: > The image change has been rolled out, which should have fixed things. > Guess there are more things missing we need to track down. Works perfectly (for RKWard), now! Thanks! Thomas pgpFmPaaKbOGd.pgp Description: OpenPGP digital signature
Re: Automated usage of Gitlab
On Sun, 3 Jul 2022 22:45:37 +1200 Ben Cooksley wrote: > Recent analysis of the logs of our Giltab instance has revealed > numerous instances of files being directly retrieved from Gitlab > (using the /raw/ API). Much to my incredible sadness, this has > included accesses being made by KDE Applications themselves. > > As a reminder, automated access to the "raw files" API of Gitlab is > strictly prohibited and not permitted under any circumstances. The > only use of it which is allowed is within .gitlab-ci.yml files to > import job definitions from sysadmin/ci-utilities. [...] To make sure I understand you, correctly: All this applies to the /raw/ API, only? For instance, on the RKWard download page, we link to the release Changelog, for convenience, as a "/-/blob/". Is that ok, or something to avoid, too? Regards Thomas pgpfwaf7bLsIi.pgp Description: OpenPGP digital signature
Re: Migrating Windows CI to Qt 6.7 - Roadblocks
On Sat, 25 May 2024 13:02:41 +0200 christ...@cullmann.io wrote: > Now that frameworks is QDBus free on Windows and macOS I would even > propose that in a next update of the stuff we really not have QtDBus > around at all on these systems and make the use optional for the apps > that want to support them. > > We go to great lengths to avoid that dbus stuff is ever called, even > deleting the dll and the most freezes you will get if that is not > done is just dbus related. > > It would be great if people could join the effort to get that right. > > https://invent.kde.org/packaging/craft-blueprints-kde/-/issues/17 Asking mostly out of curiosity, but do you have a link to a writeup / thread on the problem, and / or suggested replacements? I noticed before that you were skeptical of dbus on Windows over at kate, but since it essentially seemed to work for us in RKWard (for the very limited use-case of reusing a running instance), I never bothered to follow suit. Now I see how you replaced dbus for that use-case in kate, and I guess that'll be easy enough to copy. But if dbus is something to avoid (where possible) in the interest of present and future cross-platform compatibility, some generic guidance might be helpful. Regards Thomas pgpI8Ow1aM7FX.pgp Description: OpenPGP digital signature
Re: KDE Gear projects with failing CI (master) (6 August 2024)
On Wed, 07 Aug 2024 00:55:00 +0200 Albert Astals Cid wrote: > okular - 3rd week > * https://invent.kde.org/graphics/okular/-/pipelines/748502 > * mac craft packaging fails I do not have a proper diagnosis as to why this is failing. However, the failing lib (libgpg-error) gets pulled in via KF6Wallet. Since only the backend executable depends on the lib, it is possible to exclude it from the package using blacklisting. The following blacklist works for us in rkward (we depend on okular for craft packaging (for the part)): lib/libKF6WalletBackend.*dylib -- Side note: Is there any known procedure for testing craft packaging changes in the CI, without making changes to the "live" blueprint repository? I.e. a way to override blueprints from within a project? Regards Thomas pgpkxgJoO3q5W.pgp Description: OpenPGP digital signature
