Re: kdesrc-build expects fixed path
I think a better change would be to return to the older, simpler, shorter "flat" folder structure. See https://invent.kde.org/sdk/kdesrc-build/-/merge_requests/96 Nate On Sat, 05 Jun 2021 22:27:44 -0600 Ömer Fadıl USTA wrote > I think we need to change templates and other docs for its standard location > as$HOME/kde/src/sdk/kdesrc-build > because it already downloads its self (as a copy) whenever we run > kdesrc-buildI believe it was set up flat structure just before passing to > invent structure sonow it must be looked up in sdk folder > > Ömer Fadıl Usta > PGP key : 0xfd11561976b1690b > about.me/omerusta > > > Frederik Schwarzer , 5 Haz 2021 Cmt, 20:18 tarihinde şunu > yazdı: > Hi, > > when I just tried to set up kdesrc-build with --initial-setup it offered > me to update my .bashrc file. > > The changes made did not work for me because it adds > $HOME/kde/src/kdesrc-build > to the PATH while I have my checkout at another location. > > Maybe I have missed something but I think we should either > - print a warning or even an error message when >running "--initial-setup" from a "wrong" location > or > - add the location of the actual checkout to .bashrc > > Any thought or amendments? > > Cheers, > Frederik >
Re: Craft windows build broken for Kdiff3
The default has been set back to 1.69.0 to resolve the more general breakage. However kdiff3 can not use this version of boost headers and will block at config time by design.
Re: Craft windows build broken for Kdiff3
On Sonntag, 6. Juni 2021 19:04:11 CEST Michael Reeves wrote: > https://build.kde.org/job/Extragear/job/kdiff3/job/kf5-qt5%20WindowsMSVCQt5.15/ > > KDiff3 requires boost-headers 1.71.0 or later due to an MSVC specific > link time bug See https://github.com/boostorg/safe_numerics/issues/71. > Craft however is refusing to take the updated configuration files into > account and instead uses 1.69.0. All settings that I am aware of have > been updated. KMyMoney seems to be hit by this as well and I am pretty sure more apps are affected. Not only the Windows builds but also the ones for Mac: https://binary-factory.kde.org/job/KMyMoney_Release_win64/ https://binary-factory.kde.org/job/KMyMoney_Release_macos/ Would be cool to see some fixes. -- Regards Thomas Baumgart https://www.signal.org/ Signal, the better WhatsApp - Dogs can't operate MRI machines, but catscan -- Epic Dad jokes - signature.asc Description: This is a digitally signed message part.
Craft windows build broken for Kdiff3
https://build.kde.org/job/Extragear/job/kdiff3/job/kf5-qt5%20WindowsMSVCQt5.15/ KDiff3 requires boost-headers 1.71.0 or later due to an MSVC specific link time bug See https://github.com/boostorg/safe_numerics/issues/71. Craft however is refusing to take the updated configuration files into account and instead uses 1.69.0. All settings that I am aware of have been updated. A message has been sent to kde-windows two days ago but but there seems to have been no reply. This is operational on my test machine. I would appreciate a response from someone who knows craft. I am not subscribe to kde-windows or kde-dev but can usually see replies in the mail archives. Is there a matrix chat option. IRC is limbo at the moment I don't really have a good client anyway.
Re: Re KIO workers
On 2021-06-05 21:07, Kevin Ottens wrote: Hello, On Saturday, 5 June 2021 17:51:18 CEST David Faure wrote: On samedi 5 juin 2021 16:29:10 CEST Volker Krause wrote: > Do KIO slaves still need the klauncher/kinit loading mechanism? No. My request for developers to test KIO_FORK_SLAVES=1 for daily use is so that apps fork kio worker processes directly, without going via klauncher/kinit. BTW it seems to work fine. I wonder if we should toggle that in 5.84, as part of the incremental move to the KF6 world. Hi, I would propose to toggle this "now" and see if we get any suspicious reports in the next weeks, one can still turn it back off before the next release tagging. Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
