What will be the procedure if we ever need to add a dependency now? With
Docker it was easy because we could just edit the Dockerfile. What will be
the equivalent?
On Sat, Jun 28, 2025 at 1:23 PM Ben Cooksley wrote:
> Hi all,
>
> As part of our transition to VM based CI, i'm about to start cutti
On Sun, 18 May 2025, 08:59 Justin Zobel, wrote:
> If the contributor cannot tell you the license(s) of the code that was
> used to generate the code, then it's literally gambling that this code
> wasn't taken from another project by Gemini and used without their
> permission or used in a way that
Sorry for double posting. This worked:
https://invent.kde.org/network/kdeconnect-kde/-/blob/master/.gitlab-ci.yml?ref_type=heads#L21-28
On Fri, May 9, 2025 at 12:57 PM Albert Vaca Cintora
wrote:
> The macOS jobs are just included from templates, so I can't change them.
> But I just
nderstand it.
On Thu, May 8, 2025 at 12:10 PM Ben Cooksley wrote:
> On Thu, May 8, 2025 at 8:43 AM Ingo Klöcker wrote:
>
>> On Mittwoch, 7. Mai 2025 21:22:31 Mitteleuropäische Sommerzeit Albert
>> Vaca
>> Cintora wrote:
>> > I've disabled kdeconnect macOS build
I've disabled kdeconnect macOS builds for the release branch. I wonder if
there's a way to never build macOS builds from release branches for KDE
Connect, to save CI resources? We don't make releases from them (we point
macOS users to download builds from master directly) so those builds are
never
I've clicked the merge button. It can be re-archived now.
On Tue, Mar 25, 2025 at 4:58 PM wrote:
>
>> But you can not do that since it's archived...
>>
>> https://invent.kde.org/unmaintained/klinkstatus
>>
>> Maybe we can unarchive it momentarily? sysadmin?
>>
>
> That has now been done, please
I created a task for KDE Connect to not require DBus on Windows/MacOS [1].
I agree using DBus is not great, but it's not an easy change to make and we
have a total of zero developers on those platforms.
[1] https://invent.kde.org/network/kdeconnect-meta/-/issues/23
+1
Every time I use a KDE app on Gnome I get those unusable black-on-black
icons or some other visual issues.
Even if this is because Gnome doesn't follow some XDG spec we use, if we
can provide a workaround for Windows we should be able to provide a
workaround in Gnome.
It seems a lot of people feel conservative in favor of tarballs, so
maybe I aimed too far. At least I think the discussion brought some
interesting points that we can explore further. Some I identified:
- The tarballs should contain no changes with respect to git, or
minimal changes obviously just
Hi KDE folks,
The recent xz backdoor scandal made me realize how bad and obsolete
distributing tarballs is. The source of truth for our code are the
repositories, and releases can simply be tags on those repos.
As a big free software community, I think we should lead by example
and get rid of tar
KDE Connect has a Telegram group with 660 members (vs 100 on matrix). I
don't know if we are the exception with such a big group on Telegram, but
this is going to be a hit to our community :(
On Tue, 22 Aug 2023, 09:02 Joseph P. De Veaugh-Geiss,
wrote:
> Hello KDE community,
>
> apologies for cr
On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley wrote:
>
> Good morning Community,
>
> I'm pleased to report that this week we reached a major milestone,
> with all the necessary technical components now being in place on our
> side for our migration to Gitlab to take place.
Regarding this: is the
On Sat, Nov 9, 2019 at 6:53 PM Ben Cooksley wrote:
>
> Unfortunately Rosetta does not have the necessary free disk space, as
> the Subversion repository is approximately 80GB these days in size,
> and operating WebSVN requires a full copy of the Subversion repository
> locally in order to operate.
As we transition to Gitlab, our users find two different ways of
reporting issues: in Bugzilla and in Gitlab. Since we don't have plans
to deprecate bugzilla, is there any way we can disable issues in Gitlab?
Albert
14 matches
Mail list logo
