KDE CI: Frameworks » kio » kf5-qt5 FreeBSDQt5.15 - Build # 848 - Fixed!
BUILD SUCCESS Build URL https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20FreeBSDQt5.15/848/ Project: kf5-qt5 FreeBSDQt5.15 Date of build: Wed, 09 Jun 2021 01:14:58 + Build duration: 4 min 18 sec and counting JUnit Tests Name: projectroot Failed: 0 test(s), Passed: 59 test(s), Skipped: 0 test(s), Total: 59 test(s)Name: projectroot.autotests Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: projectroot.src.ioslaves.trash Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot.src.kpasswdserver Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)
Progress is good for us but bad for documentation
Hi, we are all making progress but the way to notice it can be painful. Looking at something you created years ago might make you cringe, but that's actually a good sign. It indicates, that you made progress. KDE is making progress as well. Here the indicator is outdated documentation. There is still quite some documentation from KDE 4 times where the technology documented already moved on to more modern times. And just as your résumé needs updating once in a while to reflect your newly acquired skills and references, documentation needs updating so it reflects the current state of KDE (as in software, places to communicate, go-to people for all the several parts of the projects, etc.). I would like to ask you to report such documentation to me. We see the topic come up here and there but it then sometimes sinks into oblivion again because it was part of a merge request that has then been merged or so. So to let me know, you can send me an email (on- or off-list) and I will create a ticket for it where further discussion can take place. Of course you could theoretically open a ticket yourself but we still need to find the best place for those topics. I will keep you posted on that one. :) So what to report? Documentation that ... - explains outdated technology or concepts like KDE 4 or HAL. - has holes in it. For example a tutorial where you suddenly think, you skipped an important step. - you wish was there but you could not find it. Thanks a bunch. :) Cheers, Frederik
Progress is good for us but bad for documentation
Hi, we are all making progress but the way to notice it can be painful. Looking at something you created years ago might make you cringe, but that's actually a good sign. It indicates, that you made progress. KDE is making progress as well. Here the indicator is outdated documentation. There is still quite some documentation from KDE 4 times where the technology documented already moved on to more modern times. And just as your résumé needs updating once in a while to reflect your newly acquired skills and references, documentation needs updating so it reflects the current state of KDE (as in software, places to communicate, go-to people for all the several parts of the projects, etc.). I would like to ask you to report such documentation to me. We see the topic come up here and there but it then sometimes sinks into oblivion again because it was part of a merge request that has then been merged or so. So to let me know, you can send me an email (on- or off-list) and I will create a ticket for it where further discussion can take place. Of course you could theoretically open a ticket yourself but we still need to find the best place for those topics. I will keep you posted on that one. :) So what to report? Documentation that ... - explains outdated technology or concepts like KDE 4 or HAL. - has holes in it. For example a tutorial where you suddenly think, you skipped an important step. - you wish was there but you could not find it. Thanks a bunch. :) Cheers, Frederik
Re: Can we get tags and tarballs for the KDE Qt patch collection
On Tue, Jun 8, 2021 at 6:36 PM Ömer Fadıl USTA wrote: > > Please don't get me wrong but naming these patches under name of KDE will > make people confuse. > That will lead people to think that it is just KDE-related. So my suggestion > is naming is something like > qt-15.3-communityN that will let everyone take these patches whether if they > are using KDE or not. The branch is already "kde/5.15", so that ship has kind of sailed... 5.15.3.kde.N would at least maintain that relationship info. -- 真実はいつも一つ!/ Always, there's only one truth!
Re: Can we get tags and tarballs for the KDE Qt patch collection
Please don't get me wrong but naming these patches under name of KDE will make people confuse. That will lead people to think that it is just KDE-related. So my suggestion is naming is something like qt-15.3-communityN that will let everyone take these patches whether if they are using KDE or not. Ömer Fadıl Usta PGP key : 0xfd11561976b1690b about.me/omerusta Johannes Zarl-Zierl , 9 Haz 2021 Çar, 01:17 tarihinde şunu yazdı: > Am Dienstag, 8. Juni 2021, 16:56:56 CEST schrieb David Faure: > > On mardi 8 juin 2021 15:04:20 CEST Nate Graham wrote: > > > That being the case, what is the problem with us tagging it as 5.15.3? > > > We would not be using our own version number but rather the one set by > > > upstream. If the issue is one of not wanting to mislead people into > > > thinking that this is some kind of officially sanctioned thing, could > it > > > be something like "5.15.3-kde-patches"? > > > > It's not just about official or not. One day the Qt Company *will* > release > > 5.15.3 (as per the KDE/FreeQt agreement), no? > > So we cannot release something called 5.15.3 which is in fact different > > (older) from what will one day be 5.15.3. > > > > I'm unsure whether we should stick to "those are patches, grab them" > > or, for convenience, giving it a version number that is more than 5.15.2, > > less than 5.15.3, says it comes from kde, and allows multiple > releases > > Setting apart the technicalities of 5.15.3 vs 5.15.2.x vs 5.15.3.kde.N, I > think the best place to come up with a solution is the KDE side, not > downstream distributions: > > If we tell people "this is just a bunch of patches, but you should really > apply them" we create a much bigger problem that nobody can tell for sure > anymore whether that particular distro version of Qt does contain the > patches > or not. If not for the packagers we should provide somewhat canonical > versions > for ourselves and save ourselves some headaches over bug triaging... > > Cheers, > Johannes > >
Re: Can we get tags and tarballs for the KDE Qt patch collection
Am Dienstag, 8. Juni 2021, 16:56:56 CEST schrieb David Faure: > On mardi 8 juin 2021 15:04:20 CEST Nate Graham wrote: > > That being the case, what is the problem with us tagging it as 5.15.3? > > We would not be using our own version number but rather the one set by > > upstream. If the issue is one of not wanting to mislead people into > > thinking that this is some kind of officially sanctioned thing, could it > > be something like "5.15.3-kde-patches"? > > It's not just about official or not. One day the Qt Company *will* release > 5.15.3 (as per the KDE/FreeQt agreement), no? > So we cannot release something called 5.15.3 which is in fact different > (older) from what will one day be 5.15.3. > > I'm unsure whether we should stick to "those are patches, grab them" > or, for convenience, giving it a version number that is more than 5.15.2, > less than 5.15.3, says it comes from kde, and allows multiple releases Setting apart the technicalities of 5.15.3 vs 5.15.2.x vs 5.15.3.kde.N, I think the best place to come up with a solution is the KDE side, not downstream distributions: If we tell people "this is just a bunch of patches, but you should really apply them" we create a much bigger problem that nobody can tell for sure anymore whether that particular distro version of Qt does contain the patches or not. If not for the packagers we should provide somewhat canonical versions for ourselves and save ourselves some headaches over bug triaging... Cheers, Johannes signature.asc Description: This is a digitally signed message part.
Re: Can we get tags and tarballs for the KDE Qt patch collection
On 6/8/21 9:02 AM, Nicolas Fella wrote: On 07/06/2021 20:46, Nate Graham wrote: Hello folks, The Fedora packagers were mentioning to me today that it would be a lot easier for them to ship Qt with our patch collection if we made tags and tarballs. Is this something we could look into doing? Nate I think it would help the discussion to know what exactly of the status quo is creating problems. The lack of tags/version number? That there is no tarball on download.kde.org? The lack of notifying when distros should update their package? Something else? I don't know those details, so hopefully any of the Fedora packagers can provide the information. Nate
Re: Can we get tags and tarballs for the KDE Qt patch collection
On 07/06/2021 20:46, Nate Graham wrote: Hello folks, The Fedora packagers were mentioning to me today that it would be a lot easier for them to ship Qt with our patch collection if we made tags and tarballs. Is this something we could look into doing? Nate I think it would help the discussion to know what exactly of the status quo is creating problems. The lack of tags/version number? That there is no tarball on download.kde.org? The lack of notifying when distros should update their package? Something else?
Re: Can we get tags and tarballs for the KDE Qt patch collection
On mardi 8 juin 2021 15:04:20 CEST Nate Graham wrote: > On 6/8/21 5:20 AM, David Redondo wrote: > > Am Dienstag, 8. Juni 2021, 12:51:35 CEST schrieb Neal Gompa: > >> You *already* are using version numbers and bumped it to 5.15.3: > >> https://blog.neon.kde.org/2021/06/04/kde-neons-qt-is-now-built-from-kdes-> > >> >> git -branches/ > > > > KDE did not bump the version number, the 5.15 (and kde/5.15) branch > > contains the commits from > > TQtC that increased the version number before it was closed. > > > > David > > That being the case, what is the problem with us tagging it as 5.15.3? > We would not be using our own version number but rather the one set by > upstream. If the issue is one of not wanting to mislead people into > thinking that this is some kind of officially sanctioned thing, could it > be something like "5.15.3-kde-patches"? It's not just about official or not. One day the Qt Company *will* release 5.15.3 (as per the KDE/FreeQt agreement), no? So we cannot release something called 5.15.3 which is in fact different (older) from what will one day be 5.15.3. I'm unsure whether we should stick to "those are patches, grab them" or, for convenience, giving it a version number that is more than 5.15.2, less than 5.15.3, says it comes from kde, and allows multiple releases -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: Can we get tags and tarballs for the KDE Qt patch collection
On Tue, Jun 8, 2021 at 9:22 AM Ahmad Samir wrote: > > On 07/06/2021 22:52, Albert Astals Cid wrote: > > El dilluns, 7 de juny de 2021, a les 20:46:25 (CEST), Nate Graham va > > escriure: > >> Hello folks, > >> > >> The Fedora packagers were mentioning to me today that it would be a lot > >> easier for them to ship Qt with our patch collection if we made tags and > >> tarballs. Is this something we could look into doing? > > > > We explicitly do not want to make releases > >https://community.kde.org/Qt5PatchCollection#Will_there_be_releases.3F > > > > Making a release means having to use of a version number, and any version > > number we use will be wrong. > > > > Don't think this as a product, think of it as a central place where patches > > are collected. > > > > If they want a tarball because using git is a problem, they can always use > > https://invent.kde.org/qt/qt/qtbase/-/archive/kde/5.15/qtbase-kde-5.15.tar.bz2 > > ? > > > > Cheers, > >Albert > > > Alternatively they could treat it like backported kernel patches? > https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/Patchlist.changelog > I don't know the > details but it's doable is what I am saying. > > The thing is, IIUC the KDE Qt patch curators don't want to create a release, > just a set of > "important" patches on top of the last open-source Qt release, i.e. deal with > it like any other > project whose upstream hasn't made any new releases in a long time, but there > are new commits in > git; I am sure most distro packagers have seen one or two cases as such. > The kernel has a weird, special workflow that no other package does. It's because the RHEL kernel and Fedora kernel sources are merged and non-upstream RHEL-ish changes are now always present in the source tree. -- 真実はいつも一つ!/ Always, there's only one truth!
Re: Can we get tags and tarballs for the KDE Qt patch collection
On 07/06/2021 22:52, Albert Astals Cid wrote: El dilluns, 7 de juny de 2021, a les 20:46:25 (CEST), Nate Graham va escriure: Hello folks, The Fedora packagers were mentioning to me today that it would be a lot easier for them to ship Qt with our patch collection if we made tags and tarballs. Is this something we could look into doing? We explicitly do not want to make releases https://community.kde.org/Qt5PatchCollection#Will_there_be_releases.3F Making a release means having to use of a version number, and any version number we use will be wrong. Don't think this as a product, think of it as a central place where patches are collected. If they want a tarball because using git is a problem, they can always use https://invent.kde.org/qt/qt/qtbase/-/archive/kde/5.15/qtbase-kde-5.15.tar.bz2 ? Cheers, Albert Alternatively they could treat it like backported kernel patches? https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/Patchlist.changelog I don't know the details but it's doable is what I am saying. The thing is, IIUC the KDE Qt patch curators don't want to create a release, just a set of "important" patches on top of the last open-source Qt release, i.e. deal with it like any other project whose upstream hasn't made any new releases in a long time, but there are new commits in git; I am sure most distro packagers have seen one or two cases as such. My 2p. Have a good day. -- Ahmad Samir
Re: Can we get tags and tarballs for the KDE Qt patch collection
On Tue, Jun 8, 2021 at 9:04 AM Nate Graham wrote: > > On 6/8/21 5:20 AM, David Redondo wrote: > > Am Dienstag, 8. Juni 2021, 12:51:35 CEST schrieb Neal Gompa: > >> You *already* are using version numbers and bumped it to 5.15.3: > >> https://blog.neon.kde.org/2021/06/04/kde-neons-qt-is-now-built-from-kdes-git > >> -branches/ > > KDE did not bump the version number, the 5.15 (and kde/5.15) branch contains > > the commits from > > TQtC that increased the version number before it was closed. > > > > David > > > That being the case, what is the problem with us tagging it as 5.15.3? > We would not be using our own version number but rather the one set by > upstream. If the issue is one of not wanting to mislead people into > thinking that this is some kind of officially sanctioned thing, could it > be something like "5.15.3-kde-patches"? > "5.15.3.kde.N" would be the convention I'd recommend (to avoid issues with various distribution version consumption mechanisms), but yeah, having snapshot releases would make life *much* simpler. -- 真実はいつも一つ!/ Always, there's only one truth!
Re: Can we get tags and tarballs for the KDE Qt patch collection
On 6/8/21 5:20 AM, David Redondo wrote: Am Dienstag, 8. Juni 2021, 12:51:35 CEST schrieb Neal Gompa: You *already* are using version numbers and bumped it to 5.15.3: https://blog.neon.kde.org/2021/06/04/kde-neons-qt-is-now-built-from-kdes-git -branches/ KDE did not bump the version number, the 5.15 (and kde/5.15) branch contains the commits from TQtC that increased the version number before it was closed. David That being the case, what is the problem with us tagging it as 5.15.3? We would not be using our own version number but rather the one set by upstream. If the issue is one of not wanting to mislead people into thinking that this is some kind of officially sanctioned thing, could it be something like "5.15.3-kde-patches"? Nate
Re: Bug #359783
В письме от вторник, 8 июня 2021 г. 15:34:30 MSK пользователь Ömer Fadıl USTA написал: > If I understand you correct you are looking at a distro with exactly using > 5.13 > then from this list : I am looking for a distro which can be bisected through dates to identify which version of Qt is broken Excluding Gentoo, bisecting there would be very slow and it's intended to use as a last resort
Re: Bug #359783
If I understand you correct you are looking at a distro with exactly using 5.13 then from this list : https://repology.org/project/qt/badges mandriva 4.0 is using it : https://sourceforge.net/projects/openmandriva/files/release/obsolete/4.0/ Ömer Fadıl Usta PGP key : 0xfd11561976b1690b about.me/omerusta Oleg Solovyov , 8 Haz 2021 Sal, 14:00 tarihinde şunu yazdı: > Hi, I'm looking for distros having snapshots with Qt 5.13. > > I've found snapshots.debian.org but there was an update 5.12 -> 5.14 > > >
Re: Can we get tags and tarballs for the KDE Qt patch collection
Am Dienstag, 8. Juni 2021, 12:51:35 CEST schrieb Neal Gompa: > You *already* are using version numbers and bumped it to 5.15.3: > https://blog.neon.kde.org/2021/06/04/kde-neons-qt-is-now-built-from-kdes-git > -branches/ KDE did not bump the version number, the 5.15 (and kde/5.15) branch contains the commits from TQtC that increased the version number before it was closed. David
Re: Can we get tags and tarballs for the KDE Qt patch collection
On Tue, Jun 8, 2021 at 10:52 PM Neal Gompa wrote: > On Mon, Jun 7, 2021 at 4:52 PM Albert Astals Cid wrote: > > > > El dilluns, 7 de juny de 2021, a les 20:46:25 (CEST), Nate Graham va > escriure: > > > Hello folks, > > > > > > The Fedora packagers were mentioning to me today that it would be a lot > > > easier for them to ship Qt with our patch collection if we made tags > and > > > tarballs. Is this something we could look into doing? > > > > We explicitly do not want to make releases > > https://community.kde.org/Qt5PatchCollection#Will_there_be_releases.3F > > > > Making a release means having to use of a version number, and any > version number we use will be wrong. > > > > Don't think this as a product, think of it as a central place where > patches are collected. > > > > If they want a tarball because using git is a problem, they can always > use > https://invent.kde.org/qt/qt/qtbase/-/archive/kde/5.15/qtbase-kde-5.15.tar.bz2 > ? > > > > You *already* are using version numbers and bumped it to 5.15.3: > > https://blog.neon.kde.org/2021/06/04/kde-neons-qt-is-now-built-from-kdes-git-branches/ > > This is unreasonable if you're going to make us need fixes from there. > I'd rather we didn't pretend this is something other than what it is: > a community maintained uplift of Qt 5.15 while Plasma works to move to > Qt 6. > > Also, that URL is unstable, you'd get different things each time you'd > fetch from it based on the HEAD of that branch. > Gitlab offers stable URLs based on a specific hash if absolutely required, see: https://invent.kde.org/qt/qt/qtbase/-/archive/2a2f3cd61f59ccec0eecb09e4a8795d7322edfcb/qtbase-2a2f3cd61f59ccec0eecb09e4a8795d7322edfcb.tar.bz2 Please note however that my previous comment on no automated access still applies. > > -- > 真実はいつも一つ!/ Always, there's only one truth! > Cheers, Ben
Bug #359783
Hi, I'm looking for distros having snapshots with Qt 5.13. I've found snapshots.debian.org but there was an update 5.12 -> 5.14
Re: Can we get tags and tarballs for the KDE Qt patch collection
On Mon, Jun 7, 2021 at 4:52 PM Albert Astals Cid wrote: > > El dilluns, 7 de juny de 2021, a les 20:46:25 (CEST), Nate Graham va escriure: > > Hello folks, > > > > The Fedora packagers were mentioning to me today that it would be a lot > > easier for them to ship Qt with our patch collection if we made tags and > > tarballs. Is this something we could look into doing? > > We explicitly do not want to make releases > https://community.kde.org/Qt5PatchCollection#Will_there_be_releases.3F > > Making a release means having to use of a version number, and any version > number we use will be wrong. > > Don't think this as a product, think of it as a central place where patches > are collected. > > If they want a tarball because using git is a problem, they can always use > https://invent.kde.org/qt/qt/qtbase/-/archive/kde/5.15/qtbase-kde-5.15.tar.bz2 > ? > You *already* are using version numbers and bumped it to 5.15.3: https://blog.neon.kde.org/2021/06/04/kde-neons-qt-is-now-built-from-kdes-git-branches/ This is unreasonable if you're going to make us need fixes from there. I'd rather we didn't pretend this is something other than what it is: a community maintained uplift of Qt 5.15 while Plasma works to move to Qt 6. Also, that URL is unstable, you'd get different things each time you'd fetch from it based on the HEAD of that branch. -- 真実はいつも一つ!/ Always, there's only one truth!
Re: Respin requests (plasma-framework, qqc2-desktop-style)
On lundi 7 juin 2021 18:46:17 CEST Kai Uwe Broulik wrote: > can we please get a respin for the plasma-framework tarball with > https://invent.kde.org/frameworks/plasma-framework/-/commit/6b932130a2805f93 > 311de47221ccd52a2071ed42 inside? Done: plasma-framework v5.83.0-rc2 487b9e42f50a7d7837aa90c35039abff8fb41010 7adf5f77d7ecf6a45626e7a329c941f6bfe21154b2ff9c6c943727b0e68f145d sources/plasma-framework-5.83.0.tar.xz On lundi 7 juin 2021 17:58:10 CEST Nicolas Fella wrote: > can we please get a respin for the qqc2-desktop-style tarball with > https://invent.kde.org/frameworks/qqc2-desktop-style/-/merge_requests/73 > inside? Done: qqc2-desktop-style v5.83.0-rc2 071366f0b7d9a9a4068b174413c85aeeb514f389 c10cbde91dc9ef1ba68d8eb8648f3b9452abdff8b38c2a6df829e2b9c8c8f3a1 sources/qqc2-desktop-style-5.83.0.tar.xz -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: Can we get tags and tarballs for the KDE Qt patch collection
On Tue, Jun 8, 2021 at 8:52 AM Albert Astals Cid wrote: > El dilluns, 7 de juny de 2021, a les 20:46:25 (CEST), Nate Graham va > escriure: > > Hello folks, > > > > The Fedora packagers were mentioning to me today that it would be a lot > > easier for them to ship Qt with our patch collection if we made tags and > > tarballs. Is this something we could look into doing? > > We explicitly do not want to make releases > https://community.kde.org/Qt5PatchCollection#Will_there_be_releases.3F > > Making a release means having to use of a version number, and any version > number we use will be wrong. > > Don't think this as a product, think of it as a central place where > patches are collected. > > If they want a tarball because using git is a problem, they can always use > https://invent.kde.org/qt/qt/qtbase/-/archive/kde/5.15/qtbase-kde-5.15.tar.bz2 > ? > Please note that automated services should not use the /archive/ endpoints provided by Gitlab - they're for human use only. The recommendation here would be for distributions to periodically manually download snapshots (using the above endpoints if they wish) and then upload those into their systems. > Cheers, > Albert > Cheers, Ben > > > > > Nate > > > > > > >