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
Hi,
A few weeks ago I was playing with Kolourpaint's sources (I used it as a
test package to port it to Windows), and I think the frameworks branch is
ready to be merged into master.
Is there any reason this can't be done? Is the project just unmaintained?
I wouldn't mind being the maintainer (i
Lxr can't search across every open source project in the world, so that's a
point for Google.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
On Fri, Oct 23, 2015 at 9:13 AM, Jeremy Whiting wrote:
> +1 and thanks for adding documentation.
>
> On Fri, Oct 23, 2015 at 9:53 AM, Aleix Pol wrote:
> > On Thu, Sep 10, 2015 at 10:32 AM, Albert Vaca
> wrote:
> >> Hi,
> >>
> >> With the latest ch
Hi again,
Aleix Pol just added some documentation to KDE Connect, so we should now
meet the criteria to move it into extragear.
Is there anything else you guys think we should review, or is the package
ready to be moved?
Albert
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to un
I don't think that having "descriptive documentation" (more about this
later) is that important nowadays, and IMO users will likely google for
help way before they use the help button when they find issues. Since most
people I talked to in Randa agreed with me on this, I'm a bit surprised to
find t
>
> I moved the translations for both repositories. Please update the
> translations
> branches for kdeconnect-android so that trunk_kf5 is master and trunk is
> none;
> yes, it's android and it does not matter, but it's easier for us.
>
Done.
> Translation branches for kdeconnect-kde are fine (
Our awesome sysadmins already moved the two repos (kdeconnect-android and
kdeconnect-kde) to Review.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
+kde-core-devel
Hi,
With the latest changes we are making to KDE Connect as part of the sprint
in Randa, I think that the project is becoming mature enough to be moved
out of playground. Not only that, but Kubuntu and other distros are already
installing KDE Connect by default, regardless of it b
+kde-core-devel
Hi,
With the latest changes we are making to KDE Connect as part of the sprint
in Randa, I think that the project is becoming mature enough to be moved
out of playground. Not only that, but Kubuntu and other distros are already
installing KDE Connect by default, regardless of it b
Hi,
With the latest changes we are making to KDE Connect as part of the sprint
in Randa, I think that the project is becoming mature enough to be moved
out of playground. Not only that, but Kubuntu and other distros are already
installing KDE Connect by default, regardless of it being in playgroun
24 matches
Mail list logo
