KDE CI: Frameworks » kio » kf5-qt5 FreeBSDQt5.15 - Build # 848 - Fixed!

2021-06-08 Thread CI System
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

2021-06-08 Thread Frederik Schwarzer

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

2021-06-08 Thread Frederik Schwarzer

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

2021-06-08 Thread Neal Gompa
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

2021-06-08 Thread Ömer Fadıl USTA
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

2021-06-08 Thread Johannes Zarl-Zierl
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

2021-06-08 Thread Nate Graham

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

2021-06-08 Thread Nicolas Fella

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

2021-06-08 Thread David Faure
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

2021-06-08 Thread Neal Gompa
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

2021-06-08 Thread Ahmad Samir

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

2021-06-08 Thread Neal Gompa
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

2021-06-08 Thread Nate Graham

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

2021-06-08 Thread Oleg Solovyov
В письме от вторник, 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

2021-06-08 Thread Ömer Fadıl USTA
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

2021-06-08 Thread David Redondo
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

2021-06-08 Thread Ben Cooksley
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

2021-06-08 Thread Oleg Solovyov
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

2021-06-08 Thread Neal Gompa
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)

2021-06-08 Thread David Faure
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

2021-06-08 Thread Ben Cooksley
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
> >
>
>
>
>
>