From aacid at kde.org  Sun Nov  3 17:56:29 2024
From: aacid at kde.org (Albert Astals Cid)
Date: Sun, 03 Nov 2024 18:56:29 +0100
Subject: KDE Frameworks with failing CI (master) (3 November 2024)
Message-ID: <3285236.nM3bZYvNSe@xps15>

Please work on fixing them, otherwise i will remove the failing CI jobs on 
their 4th failing week, it is very important that CI is passing for multiple 
reasons.

Good news: 1 repository was fixed

Bad news: 1 repository is still failing, 1 repository has started failing


kdav - 2nd week
 * https://invent.kde.org/frameworks/kdav/-/pipelines/810053
  * kdav-davitemfetchjob fails


attica - NEW
 * https://invent.kde.org/frameworks/attica/-/pipelines/810052
  * providertest fails


Cheers,
  Albert



From vkrause at kde.org  Mon Nov  4 16:53:14 2024
From: vkrause at kde.org (Volker Krause)
Date: Mon, 04 Nov 2024 17:53:14 +0100
Subject: KDE Frameworks with failing CI (master) (3 November 2024)
In-Reply-To: <3285236.nM3bZYvNSe@xps15>
References: <3285236.nM3bZYvNSe@xps15>
Message-ID: <2758139.mvXUDI8C0e@vkpc5>

On Sonntag, 3. November 2024 18:56:29 Mitteleuropäische Normalzeit Albert 
Astals Cid wrote:
> Please work on fixing them, otherwise i will remove the failing CI jobs on
> their 4th failing week, it is very important that CI is passing for multiple
> reasons.
> 
> Good news: 1 repository was fixed
> 
> Bad news: 1 repository is still failing, 1 repository has started failing
> 
> 
> kdav - 2nd week
>  * https://invent.kde.org/frameworks/kdav/-/pipelines/810053
>   * kdav-davitemfetchjob fails

Small behavior change in Qt 6.8's HTTP code:
https://invent.kde.org/frameworks/kdav/-/merge_requests/40

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20241104/f4aaf910/attachment.sig>

From nicolas.fella at gmx.de  Fri Nov  8 13:48:15 2024
From: nicolas.fella at gmx.de (Nicolas Fella)
Date: Fri, 8 Nov 2024 14:48:15 +0100
Subject: KDE Frameworks 6.8
Message-ID: <06b3dc94-215e-4505-a284-4a168c8c5431@gmx.de>

Hi,

KDE Frameworks 6.8 is now available:
https://kde.org/announcements/frameworks/6/6.8.0/

Cheers

Nico


From aacid at kde.org  Sun Nov 10 10:32:15 2024
From: aacid at kde.org (Albert Astals Cid)
Date: Sun, 10 Nov 2024 11:32:15 +0100
Subject: KDE Frameworks with failing CI (master) (10 November 2024)
Message-ID: <5640449.TH9apptTdW@xps15>

Please work on fixing them, otherwise i will remove the failing CI jobs on 
their 4th failing week, it is very important that CI is passing for multiple 
reasons.

Good news: All repositories are passing 

Cheers,
  Albert






From murveit at gmail.com  Sat Nov 16 07:22:51 2024
From: murveit at gmail.com (Hy Murveit)
Date: Fri, 15 Nov 2024 23:22:51 -0800
Subject: KNewStuff web caching
Message-ID: <CA+B1P8tyO_q01qdp1i46ahWTvgqPX0UisbBWGd8nA4Z9-MQ=gA@mail.gmail.com>

I have a question about web-caching related to KNewStuff.

*Background*
I am a KStars developer, and asked Jasem (KStars lead) to post some "new
stuff" for me.
He did (or perhaps asked someone else to) and now when one goes to
https://cdn.kde.org/edu/kstars/main.xml one gets a list that includes my
"new stuff".

Actually the kstars.knsrc says ProvidersUrl=
https://indilib.org/jdownloads/knewstuff/providers.xml
but when you go there it returns

<knewstuffproviders>
<provider downloadurl="https://edu.kde.org/kstars/downloads/main.xml"
nouploadurl="https://edu.kde.org/contrib/" icon="
http://edu.kde.org/pics/projects/cr32-app-kstars.png">
<title>KStars Data</title>
</provider>
<provider downloadurl="https://indilib.org/jdownloads/knewstuff/dso.xml"
nouploadurl="https://edu.kde.org/contrib/" icon="
http://edu.kde.org/pics/projects/cr32-app-kstars.png">
<title>KStars Data</title>
</provider>
</knewstuffproviders>


and https://edu.kde.org/kstars/downloads/main.xml redirects to
https://cdn.kde.org/edu/kstars/main.xml

Anyway, here's the new item:

<stuff>
<name>ImagingPlanner Catalog1</name>
<type>ImagingPlanner</type>
<author email="kstars-devel at kde.org">Hy Murveit</author>
<licence>Free noncommercial ShareAlike use with credit. Creative Commons
license. Credit for individual images in .csv files.</licence>
<summary lang="en">Catalog 1 for the KStars ImagingPlanner tool.</summary>
<version>1.0</version>
<release>1</release>
<releasedate>2024-11-06</releasedate>
<downloadsize1>6700</downloadsize1>
<preview lang="en">
https://cdn.kde.org/edu/kstars/previews/imagingplanner-screenshot.jpg
</preview>
<payload lang="en">
https://cdn.kde.org/edu/kstars/ImagingPlanner-catalog1.tar.gz</payload>
<rating>5</rating>
<downloads>0</downloads>
</stuff>


I successfully use my browser to download/see
https://cdn.kde.org/edu/kstars/ImagingPlanner-catalog1.tar.gz
or
https://cdn.kde.org/edu/kstars/previews/imagingplanner-screenshot.jpg
So, all seems cool when using browsers!

*The problem*
The problem is that I can't see the new content from within KStars' KF5
implementation of KNewStuff. I just see the "stuff" that existed before.
Other folks using KStars on other machines do see my new stuff. Since I can
see it with my browsers, and others can see it from within KStars, I assume
the problem is that somehow/somewhere in the KDE libraries my local machine
is caching the older web pages so that when KNewStuff goes to fetch it, it
only sees the cached old content.

Is that possible? If so, how would I clear that web cache?  This happens
both when I run KStars on my Mac laptop, and when I run it on an Ubuntu VM
on my laptop.  It doesn't happen on browsers from those machines (but I did
clear the browser's caches when I had this problem early on).

Also, do you think there's a caching configuration issue on the hosting web
server for that page?

Thanks,
Hy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20241115/f593936f/attachment.htm>

From bcooksley at kde.org  Sat Nov 16 07:53:26 2024
From: bcooksley at kde.org (Ben Cooksley)
Date: Sat, 16 Nov 2024 20:53:26 +1300
Subject: KNewStuff web caching
In-Reply-To: <CA+B1P8tyO_q01qdp1i46ahWTvgqPX0UisbBWGd8nA4Z9-MQ=gA@mail.gmail.com>
References: <CA+B1P8tyO_q01qdp1i46ahWTvgqPX0UisbBWGd8nA4Z9-MQ=gA@mail.gmail.com>
Message-ID: <CA+XidOE2KR2V4XnU5BErHN7BC4Q3NJ1nNyvThu6jioF+Cu50Xg@mail.gmail.com>

On Sat, Nov 16, 2024 at 8:27 PM Hy Murveit <murveit at gmail.com> wrote:

> I have a question about web-caching related to KNewStuff.
>

Hi Hy,


>
> *Background*
> I am a KStars developer, and asked Jasem (KStars lead) to post some "new
> stuff" for me.
> He did (or perhaps asked someone else to) and now when one goes to
> https://cdn.kde.org/edu/kstars/main.xml one gets a list that includes my
> "new stuff".
>
> Actually the kstars.knsrc says ProvidersUrl=
> https://indilib.org/jdownloads/knewstuff/providers.xml
>

This file really should be on autoconfig.kde.org.


> but when you go there it returns
>
> <knewstuffproviders>
> <provider downloadurl="https://edu.kde.org/kstars/downloads/main.xml"
> nouploadurl="https://edu.kde.org/contrib/" icon="
> http://edu.kde.org/pics/projects/cr32-app-kstars.png">
> <title>KStars Data</title>
> </provider>
> <provider downloadurl="https://indilib.org/jdownloads/knewstuff/dso.xml"
> nouploadurl="https://edu.kde.org/contrib/" icon="
> http://edu.kde.org/pics/projects/cr32-app-kstars.png">
> <title>KStars Data</title>
> </provider>
> </knewstuffproviders>
>
>
> and https://edu.kde.org/kstars/downloads/main.xml redirects to
> https://cdn.kde.org/edu/kstars/main.xml
>

That provider file should be updated to refer to the new home of those
resources to minimise unnecessary traffic being sent to edu.kde.org (which
is not CDN backed).
We would have caught that had it been hosted on KDE infrastructure.


>
> Anyway, here's the new item:
>
> <stuff>
> <name>ImagingPlanner Catalog1</name>
> <type>ImagingPlanner</type>
> <author email="kstars-devel at kde.org">Hy Murveit</author>
> <licence>Free noncommercial ShareAlike use with credit. Creative Commons
> license. Credit for individual images in .csv files.</licence>
> <summary lang="en">Catalog 1 for the KStars ImagingPlanner tool.</summary>
> <version>1.0</version>
> <release>1</release>
> <releasedate>2024-11-06</releasedate>
> <downloadsize1>6700</downloadsize1>
> <preview lang="en">
> https://cdn.kde.org/edu/kstars/previews/imagingplanner-screenshot.jpg
> </preview>
> <payload lang="en">
> https://cdn.kde.org/edu/kstars/ImagingPlanner-catalog1.tar.gz</payload>
> <rating>5</rating>
> <downloads>0</downloads>
> </stuff>
>
>
> I successfully use my browser to download/see
> https://cdn.kde.org/edu/kstars/ImagingPlanner-catalog1.tar.gz
> or
> https://cdn.kde.org/edu/kstars/previews/imagingplanner-screenshot.jpg
> So, all seems cool when using browsers!
>
> *The problem*
> The problem is that I can't see the new content from within KStars' KF5
> implementation of KNewStuff. I just see the "stuff" that existed before.
> Other folks using KStars on other machines do see my new stuff. Since I can
> see it with my browsers, and others can see it from within KStars, I assume
> the problem is that somehow/somewhere in the KDE libraries my local machine
> is caching the older web pages so that when KNewStuff goes to fetch it, it
> only sees the cached old content.
>

> Is that possible? If so, how would I clear that web cache?  This happens
> both when I run KStars on my Mac laptop, and when I run it on an Ubuntu VM
> on my laptop.  It doesn't happen on browsers from those machines (but I did
> clear the browser's caches when I had this problem early on).
>

As a starting point you should probably use kdebugdialog5 to enable all the
relevant debug output and capture the necessary logs to ensure KStars as
built on your machine is actually fetching what you think it is trying to
fetch and isn't fetching some old archive from elsewhere. KStars seems to
have KNewStuff content scattered around both cdn.kde.org and files.kde.org
so there is a possibility you are referencing an old file.


>
> Also, do you think there's a caching configuration issue on the hosting
> web server for that page?
>

Our CDN network is aggressively cached as the CDN relies on the CDN PoPs
fetching files from our backend server on first request and then holding a
cached copy.
For those wondering why we use this approach - Edge storage is
prohibitively expensive and we have ~188GB of data on cdn.kde.org (although
that is comparatively small vs. the 895GB of download.kde.org and 729GB of
files.kde.org).


>
> Thanks,
> Hy
>

Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20241116/56c9633e/attachment.htm>

From aacid at kde.org  Sun Nov 17 23:01:46 2024
From: aacid at kde.org (Albert Astals Cid)
Date: Mon, 18 Nov 2024 00:01:46 +0100
Subject: KDE Frameworks with failing CI (master) (17 November 2024)
Message-ID: <38487578.7tKJWyACHI@xps15>

Please work on fixing them, otherwise i will remove the failing CI jobs on 
their 4th failing week, it is very important that CI is passing for multiple 
reasons.

Good news: All repositories are passing 

Cheers,
  Albert