Re: What can we expect from our developers

2024-01-30 Thread Ingo Klöcker
On Dienstag, 30. Januar 2024 21:47:51 CET Friedrich W. H. Kossebau wrote:
> I think I understand where you are coming from, that all the work on
> software done here makes the more sense the more users there are. IMHO
> though reaching more users of Free Software should be done in ways and for
> platforms which are not giving more power to monopolists or those which
> seem set to become some. Flatpak, Snap, Windows, macOS... they are all
> about binaries. There is no simple way, part of the concept, to get the
> sources, patch something to one's likes and then regenerate the very same
> package, just as custom one. Or is there?

Yes, there is. They can simply use our infrastructure for this. We are doing 
much more than just providing the sources. We provide the fully functional CI/
CD machinery for building custom versions (minus digital signatures which we 
reserve for our official release artifacts).

Regards,
Ingo

signature.asc
Description: This is a digitally signed message part.


Re: What can we expect from our developers

2024-01-30 Thread Friedrich W. H. Kossebau
Am Montag, 29. Januar 2024, 10:38:11 CET schrieb Sune Vuorela:
> On 2024-01-29, Jonathan Riddell  wrote:
> > This sort of comment  makes me really sad. The All About the Apps goal,
> > which in principle is still ongoing, was an attempt to get KDE developers
> > to realise it was important not just to write apps but to actually make
> > them available to users, I find it astonishing how we still don't have a
> > culture where making our apps available to users is part of our
> > responsibility.  There's teams in KDE to help with all these formats.
> > Sorry to complain here as the issue is larger than just this one app but
> > it's so sad that nobody within KDE wants to help get users using our
> > software directly.
> 
> I think this is taking it too far. I think the goal is more about not
> getting in the way of people who wants to do this.

What Sune says.

I am sorry to be among those saddening you by not living up to your hopes.

To share you my perspective, for me almost all of these platforms are the same 
challenge as I face with localizations: I do not speak the "language" or live 
the "culture", thus cannot do anything effectively there to properly integrate 
the artifact generated from the sources written.
I have only x leisure time to spend, so I spend it on the things I feel I 
understand & can responsibly create proper results at. And leave it to the 
domain experts to do what is needed or useful in their field. Like 
translators, to localize things for a given locale. Or packagers, to generate 
the binary blobs which work on a given platform. Or sysadmin, to maintain and 
run the environment which only enables us to work on software here in this 
place.

Next, making apps available to users on their platforms also means supporting 
them there. Which again needs proper clue (and access to those platforms) to 
be effective with the given resources one can take from ones capabilities.

I am sharing the result of my developing efforts here as sources, by a very 
grateful license which also emphasizes the sources, not some platform specific 
binary blob. To allow those interested to make use of the product with their 
platforms of choices/realities, adapting and enhancing it where they want to 
their desires. 
Similar to making the software localizable, so those interested can make it 
fit their local culture. Likewise visual styles or other configuration 
options.

Additionally:
I think I understand where you are coming from, that all the work on software 
done here makes the more sense the more users there are. IMHO though reaching 
more users of Free Software should be done in ways and for platforms which are 
not giving more power to monopolists or those which seem set to become some. 
Flatpak, Snap, Windows, macOS... they are all about binaries. There is no 
simple way, part of the concept, to get the sources, patch something to one's 
likes and then regenerate the very same package, just as custom one. Or is 
there?
Which makes the apps basically "free beer apps" for those users. Not the 
business I am here for. But again, packaging is not my domain anyway.

Cheers
Friedrich




Re: Ready-to-use Docker images for KF6-based development ?

2024-01-30 Thread Jonathan Riddell
*Sure, the Neon unstable one should be ready to go*
*invent-registry.kde.org/neon/docker-images/plasma:unstable
*

*You can try Distrobox to give it a go in a more managed way *
https://community.kde.org/Neon/Containers

Or manually something like
docker run -ti --volume="$HOME/.Xauthority:/root/.Xauthority:rw"
--network=host -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=:0
--security-opt seccomp=unconfined
invent-registry.kde.org/neon/docker-images/plasma:unstable bash



On Mon, 29 Jan 2024 at 21:18, Alexander Neundorf  wrote:

> Hi,
>
> I'm still running a Qt5/KF5-based setup on my machine.
> Is there a ready-to-use docker image/Dockerfile which I could use to work
> on a
> KF6-based application, maybe something from KDE neon ?
>
> Sorry for the maybe stupid question
> Alex
>
>
>
>


Re: Ready-to-use Docker images for KF6-based development ?

2024-01-30 Thread Ben Cooksley
On Tue, Jan 30, 2024 at 10:17 AM Alexander Neundorf 
wrote:

> Hi,
>

Hi Alex,


>
> I'm still running a Qt5/KF5-based setup on my machine.
> Is there a ready-to-use docker image/Dockerfile which I could use to work
> on a
> KF6-based application, maybe something from KDE neon ?
>

I'd suggest taking a look at invent.kde.org/sysadmin/ci-images which has a
number of images that contain dependencies for just about all KDE software.
These images are used by the CI system and are published in the container
registry so you don't have to build them yourself - you can just "docker
pull" them and you should be good to go.

The Linux images there are based on OpenSUSE and are based on the
assumption you will be building all KDE software (including Frameworks and
Phonon) yourself but you could easily install those if you wanted.


>
> Sorry for the maybe stupid question
> Alex
>

Cheers,
Ben