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. :(