seems that digikam's repo is now same as release tarball. i've changed the rules file to reflect this and there are packages in unstable and stable again.

just to save future google fu headaches - https://salsa.debian.org/elbrus/britney2

Cool. Jenkins is fine as-is 👍

Based on the above I don't think so.

Seems to working well now. I've now moved build.neon to use invent for authentication. Did we have any other applications linked to phabricator?

Sorry, there was a rule in the Apache configuration blocking anything Java from accessing anything on invent.kde.org - as we were being indexed/receiving excessively heavy traffic from a Java client.
I've now tweaked that rule to be a little more specific (that indexer still seems to be hanging around) so it shouldn't hit Neon's Jenkins instance.

Also happens for the actual oauth flow

curiously the well known endpoint 403s, but only inside jenkins, curling on spara works just fine

OpenID Connect would definitely be preferrable - and will also give you access to information about groups (teams).

This would be easier if you made me gitlab admin :P

User edition repository has no arm64 packages any more, only for testing and unstable editions. Also, no neon-desktop package exists for testing, only for unstable edition.

sorry, now in debian

[14:11] <bshah[m]> Yeet

ubiquity is no longer used

We've been calamarized

I was right. More to the point openqa is out of service for the time being anyway

Limiting snapshots to a single version would actually be really ill advised. We've seen in the not so distance history that breakage can sneak into a snapshot still and for quick workarounds it is useful for the user to be able to install an older version manually. As such we'll not want to move on this. Also chances are asgen was improved since so it's not clear if this is even still an issue, I certainly haven't noticed it

At the moment LabPlot doesn't even run on Neon (Cantor installed). Error:

While very nifty that wouldn't improve things a lot. Instead of being not installable we'd make them... not installable ^^

All ubuntu components are being masked now as we want to see how that plays out. Discover is being a bit meh because it still lists the packages if they match the query something that could be improved for sure

To block stuff in APT itself, we could always refer to how Linux Mint blocks 'snapd' in the package 'mintsystem' in Linux Mint 20, but instead limit it to only blocking X (where X = the package needing blocking) package on the 'Ubuntu' component so that if users have external package sources for X package they can still install it from those external package sources. The method Mint uses can be used for any package, in principle.

I mean, if a difficulty with this is 'not simple for beginners', people can always push KDE as much as they can towards a direction, in the vanilla representation, that is a simple for beginners Operating System.

Actually the code is at https://invent.kde.org/system/ubiquity-slideshow-neon (currently awkwardly ad-hoc converts html to qml because we needed to support both, a requirement that has gone away now)

As an update, prompted by @aronkvh 's comments: the actual KDE neon slideshow lives under https://invent.kde.org/neon/neon/calamares-settings , you'll need to find the slideshow.qmland patch that up with suitable QML, or go with an images-only slideshow which is easy to do (list of filenames in YAML) but suffers from scaling issues (although, TBH all of Calamares does).

I just found this but I think the pictures showed while installation could be different.
like this for ex.:

Looks like this got done.

Aleix and I were talking about this kind of thing a while ago and the only way I could think of is T11720 which is a fairly weak approach in general because people insist on using the CLI and still have the same problem.

Mostly covered by T11720

I feel like we've had env exporting somewhere in startplasma

Sure, anything's possible. :) My point was that Neon is explicitly a KDE-centric distro. Breakage in non-KDE software is expected and normal; it's not supported at all. If there's a viable way to enable this only when using KWin, that would be idea. If not, I personally still think it's worth doing anyway to improve the experience for neon's target audience of KDE Plasma users.

Users are free to do that because Neon has Ubuntu archives enable, which has a lot of desktops available, so there's non-zero probability of breaking Firefox for those people that like evaluating different DEs and switch between them some times. Advantage of Neon in this case will be to have latest KDE. One may also enable Mint archives and get the latest Cinnamon and MATE as well. Enable some ppa or some repo and you get the latest packages for different DE.

Out of curiosity, why would you do that? What's the advantage of Neon over a different distro if you're not going to use a different DE or window manager?

I installed neon myself following the first 4 steps from https://ubuntu.com/download/raspberry-pi/thank-you?version=18.04&versionPatch=.4&architecture=arm64+raspi3
Then,

wget -qO - 'http://archive.neon.kde.org/public.key' | sudo apt-key add -
sudo apt-add-repository http://archive.neon.kde.org/user
sudo apt-get update
sudo apt-get install neon-desktop
sudo apt remove gnome-terminal

Given that Neon is a KDE-focused environment, I don't think there's a huge risk of people not using KWin.

In T13335#234059, @sitter wrote:

It's not about the risk, it's the fact that injecting env vars into firefox is a fragile hack. I mean, it's always a hack, it just happens to be particularly fragile the way it is currently done because we only force portals on firefox. Perhaps we could set it globally, but are we sure this doesn't mess with thunderbird?

Actually, about setting it globally, does it not cause adverse side effects when used with wayland? See, it's a right worry :(

It's not about the risk, it's the fact that injecting env vars into firefox is a fragile hack. I mean, it's always a hack, it just happens to be particularly fragile the way it is currently done because we only force portals on firefox. Perhaps we could set it globally, but are we sure this doesn't mess with thunderbird?

The right approach would be for the GTK developers to accept Vlad's patch to fix it for everyone, but of course nothing's easy with those people. :(

Eeeeh, I actually wanna get away from injecting env vars into firefox with firefox 78. Surely the right approach would be for firefox to check what WM it runs under and then conditionally enable this magic?

This is since fixed and supposedly pause and unpause no longer leave paused pipelines around, which is all we needed from this anyway.

https://github.com/pangea-project/pangea-tooling/commit/8ff2aa91db3640d3a8eb3eff6bf3781fd40f0254

It has been put up again at blufire.xyz

https://plasma-bigscreen.org has images for Rpi4 build on neon. Maybe you can join efforts?

It is going to be put up again

It has been taken down

The link doesn't work. Did you also created the repositories? Where can I found the seeds?

What about 'Freedom for everyone'? Thanks, KonqiDragon!

Ah, I created it. Download at blufire.xyz/downloads

Running Plasma in an Rpi 4 with 4Gb of RAM using Raspbian. So far so good but a bit outdated (plasma 5.14). I would love to see a neon spin for Rpi

I think Raspberry Pi will overheated, or could to make some Raspberry Pi Edition of Neon with "Plasma Lite Mode"? By the way Raspberry Pi is not power thing, it makes no sense.

Yeah, the repo also needs adding to some binary-factory-tooling file. And I guess the build should be green first on neon, last thing I know they were stuck in some Qt migration limbo and not building. Them not building on neon makes it hard to move ^^

So does this just need snapcraft.yaml file moved form neon packaging repo to the relevant KDE repo?

In T12707#221268, @ngraham wrote:

I agree, the proposed "KDE OS" version of Neon should continue to strive to be as vanilla as possible. It doesn't make sense to create a showpiece for KDE software that diverges from what KDE software does by default. If the default is bad, change the default. :)

I think a large part of this task is simply admitting that Neon is already an OS, and being proud of this fact rather than trying to hide it in the futile effort to avoid upsetting people who are already upset. Slimbook ships it on hardware. My wife who is sitting next to me has it on her laptop. It's an OS; if it walks like a duck and quacks like a duck, it is a duck. :)

I agree, the proposed "KDE OS" version of Neon should continue to strive to be as vanilla as possible. It doesn't make sense to create a showpiece for KDE software that diverges from what KDE software does by default. If the default is bad, change the default. :)

I am not sure what the plan is. It hasn't really been formulated, has it?

Let's not get sidetracked with the promo angle too early. Paul is right: we need to decide on a course of action and then execute the plan before we promote the message we want to communicate as a result of this plan.

Let's not get sidetracked with the promo angle too early. Paul is right: we need to decide on a course of action and then execute the plan before we promote the message we want to communicate as a result of this plan.

Get people on board, make some progress, hit some milestones, and then we'll see.g at it objectively.

Again: do the other stuff and then we'll talk Promo. We cannot start working on promotion on something that has not happened, because it may not happen, and then we would be wasting time and resources.

In T12707#220975, @paulb wrote:

I don't think Promo is the place to start carrying out this task. It seems to me that you would need to incentivise some deeper changes in KDE neon before thinking of promoting it as feature-complete distribution. As you say:

I really want to see KDE neon as the flagship os, but to realistically, this is requires to (hard) development.

And the Promo workboard is not where you should be asking for support to do that, (a) because we don't do that kind of thing in Promo -- it is more a developer/packager thing; and (b) because we don't tell others what they should do. We work with the end product, not influence (or try to influence) what that end product should be.

I do agree that this would be a good thing to promote when the first part, the part where you turn neon into a feature-complete distribution, is completed, but to carry out that, I think you have to take this task to another board.

I don't think Promo is the place to start carrying out this task. It seems to me that you would need to incentivise some deeper changes in KDE neon before thinking of promoting it as feature-complete distribution. As you say:

I generally agree.

done in neon, now time to get it into debian

Revisit for 20.04 I guess. Not much worth putting effort into this now.

In T12400#216194, @ouwerkerk wrote:

If I understand "the Neon position" correctly here, Neon aims to be the base OS + Plasma desktop. The only reason it still bothers with packaging apps is because it has to because nobody is going to use an empty shell, and the Linux world isn't all app-ified yet.

If I understand "the Neon position" correctly here, Neon aims to be the base OS + Plasma desktop. The only reason it still bothers with packaging apps is because it has to because nobody is going to use an empty shell, and the Linux world isn't all app-ified yet.

I think this started out as the idea that Neon (not KDE in general, but Neon in particular) should be more "opinionated" with regards to which next-gen packaging format it steers users towards. If that's a no-go, then I guess there's nothing to do here, and we should just focus on increasing the coverage for our apps on Snap and Flatpak (and AppImage too, I guess?).

As far as I am aware our flatpaks are purely packaging formats and don't take advantage of any sandboxing features. So I don't see what is there to recommend our flatpak implementation over our snap implementation, say. But then again, that could be part of this: pushing the packaging forward.
On the other hand: has anybody asked the application developers about their opinion on this? After all, they will be expected to take on additional maintenance efforts to make sure their app continue to work well with the chosen packaging format and they might just have opinions on that.

I'm not clear on the purpose of this task. KDE neon wants to support using every package format so our users can install and use software in any format it comes in.

In T12400#214574, @ngraham wrote:

BTW The point seems moot for Dolphin since there's already a Flatpak version of it.

True, but that's a one-time thing for each app though, right? Once it's done, the release team mostly needs to take care of releasing it as new versions come out.