Let's close it, I am guessing this is a non-issue given there were no reports to the contrary

All remaining uses and follow up issues of xenial have been dealt with and the series is now fully dead. All jenkins jobs are gone and the ci tooling no longer knows what xenial even means.

neon-settings will now attempt to remove the kf5 snap when it is found to be unused as previously mentioned. the core18 snap will be installed on-demand should the user opt to install one of the kde snaps that use it.

Exploded shortly after landed in user edition by somehow managing to block sddm for some users and in a probably related matter blocked systemd-analyze from analyzing because it considered the unit part of the startup chain. I had to make the impl changes from the previous comment to resolve that. It's now written in a sane language, increments the sleep time, and no longer systemd singleshot. No further issues.
Bhushan and Aleix also talked to upstream about actually fixing the system to "preseed" remotes via /etc, so perhaps come 20.04 we'll not need this crappy workaround anymore.

I was delighted to find that all existing code is already so smart that it only iterates on known NCI.series, so dropping or adding stuff will add/remove it from iteration as one would expect.

so much time has passed since this task was created that there is no so much red stuff that it'd be futile to even attempt resolving this -.-

Similarly to T10105 there is no real value in this.

Done alongside T10102

Tooling changes dropping the runtime to be pushed soon.

This is done kinda, sorta. Some builds are still bust, but from what I see they don't matter much. Can just fix them up at a later point in time.

I've thought about this a bit. And I am rather of the opinion that the preseed can go away. Originally we introduced it as a stop-gap because snapd didn't know how to install content snaps automatically, now it does. On top of that was the appeal of having the snaps be cheaper, but, in reality they aren't really, you just happen to download it along with the ISO. Now while that certainly does make sense to a degree it's also somewhat silly to only preseed the content snap itself, instead I'd much rather have preseeded applications be snaps. As it stands right now the preseed serves no actual purpose anymore and should be removed. If and when it makes a return I'd think it would be in the form of application dependency.

analitza
https://packaging.neon.kde.org/kde/analitza.git/log/?h=Neon/unstable_merge
MERGED 1/29
https://build.neon.kde.org/job/bionic_unstable_kde_analitza/

This is kind of done

phonon
https://packaging.neon.kde.org/extras/phonon.git/log/?h=Neon/unstable_merge
MERGED 1/15
https://build.neon.kde.org/job/bionic_unstable_extras_phonon/

The default-testpage.pdf in breeze is a neon specific change and shouldn't go back to Debian

can you answer about printer diff?
Breeze
https://packaging.neon.kde.org/kde/breeze.git/log/?h=Neon/unstable_merge
MERGED - 12/7
UPDATED - 12/8&12/9
https://build.neon.kde.org/job/bionic_unstable_kde_breeze/
Notes:
There is still a diff with the default printer page that looked very Neon specific. I need to know if this is not the case and needs to be upstreamed to debian.

kwallet-pam:
follow Debian I think (add breaks/replaces of course)

kdeplasma-addons:
keep our kwin-addons.lintian-overrides
keep our libplasmapotdprovidercore-dev.install but discuss with frinring (Friedrich W. H. Kossebau <kossebau@kde.org>) if the files should be installed
plasma-dataengines-addons.install keep our additions
plasma-dataengines-addons.lintian-overrides keep whichever one keeps lintian quiet

kdeplasma-addons:
diff --git a/debian/kwin-addons.lintian-overrides b/debian/kwin-addons.lintian-overrides
new file mode 100644
index 0000000..849c8df

• /dev/null

+++ b/debian/kwin-addons.lintian-overrides
@@ -0,0 +1,4 @@
+# kwin-addons can never be a build depends. it is a convenience metapackage to
+# get all kwin addons. If it ever was pulled in as build deps that'd be a bug
+# which ought to get fixed.
+kwin-addons: virtual-package-depends-without-real-package-depends depends: kwin
diff --git a/debian/libplasmapotdprovidercore-dev.install b/debian/libplasmapotdprovidercore-dev.install
new file mode 100644
index 0000000..553a5c7

• /dev/null

+++ b/debian/libplasmapotdprovidercore-dev.install
@@ -0,0 +1,4 @@
+usr/include/plasma/potdprovider/
+usr/lib/*/cmake/PlasmaPotdProvider/
+usr/lib/*/libplasmapotdprovidercore.so
+usr/share/kdevappwizard/templates/plasmapotdprovider.tar.bz2
diff --git a/debian/plasma-dataengines-addons.install b/debian/plasma-dataengines-addons.install
index fdb1a25..906d906 100644

• a/debian/plasma-dataengines-addons.install

+++ b/debian/plasma-dataengines-addons.install
@@ -12,4 +12,6 @@ usr/share/kservices5/plasma-dataengine-comic.desktop
usr/share/kservices5/plasma-dataengine-konsoleprofiles.desktop
usr/share/kservices5/plasma-dataengine-potd.desktop
usr/share/kservicetypes5/plasma_comicprovider.desktop
+usr/share/metainfo/org.kde.plasma.konsoleprofiles.appdata.xml
+usr/share/plasma/plasmoids/org.kde.plasma.konsoleprofiles/
usr/share/plasma/services/org.kde.plasma.dataengine.konsoleprofiles.operations
diff --git a/debian/plasma-dataengines-addons.lintian-overrides b/debian/plasma-dataengines-addons.lintian-overrides
index 49b91ee..a222d7f 100644

• a/debian/plasma-dataengines-addons.lintian-overrides

+++ b/debian/plasma-dataengines-addons.lintian-overrides
@@ -1,4 +1,2 @@
-plasma-dataengines-addons: package-name-doesnt-match-sonames libplasmacomicprovidercore1
-plasma-dataengines-addons: no-symbols-control-file usr/lib/librtm.so.4.10.*
-plasma-dataengines-addons: no-symbols-control-file usr/lib/libplasmaweather.so.4.10.*
-plasma-dataengines-addons: no-symbols-control-file usr/lib/libplasmacomicprovidercore.so.1.0.0
+plasma-dataengines-addons: package-name-doesnt-match-sonames libplasmacomicprovidercore1 libplasmapotdprovidercore1
+plasma-dataengines-addons: dev-pkg-without-shlib-symlink usr/lib/x86_64-linux-gnu/libplasmacomicprovidercore.so.1.0.0 usr/lib/x86_64-linux-gnu/libplasmacomicprovidercore.so

For breeze-plymouth I'd say keep most of our functional changes
keep our:
debian/rules
debian/plymouth-theme-breeze.prerm
debian/plymouth-theme-breeze.postinst
debian/plymouth-theme-breeze.casper-stop-breeze-plymouth.service
debian/initramfs-hook/plymouth_breeze
otherwise keep debian versions

Breeze
https://packaging.neon.kde.org/kde/breeze.git/log/?h=Neon/unstable_merge
MERGED - 12/7
UPDATED - 12/8&12/9
https://build.neon.kde.org/job/bionic_unstable_kde_breeze/
Notes:
There is still a diff with the default printer page that looked very Neon specific. I need to know if this is not the case and needs to be upstreamed to debian.

Kconfigwidgets merge in what Debian has and fix in debian?
plasma-framework work out if not having mesa-common-dev as a build dep has any differences
knewstuff: remove that rule the file isn't installed any more

Syndication is now part of KDE Frameworks so it should have the same signing key as the other frameworks. Push that to Debian if that's not the case there.

so essentially I need to merge our kirigami2 into kirigami ( Neon branches ) - then merge master and then we dump the kirigami2 and kirigami1 and left with only kirigami - I think we need to update jobs to point to kde/kirigami? no trailing 1 or 2.

In T8586#169475, @jriddell wrote:

I wonder if I merge these - should resolve the issue?

peruse in neon only uses kirigami2
plasma-sdk only uses kirigami2 ?
kube doesn't seem to use any kirigami (from a grep of source) so try just removing it there

so I think that means we can kill off kirigami1 packaging and merge in debian's one

so essentially I need to merge our kirigami2 into kirigami ( Neon branches ) - then merge master and then we dump the kirigami2 and kirigami1 and left with only kirigami - I think we need to update jobs to point to kde/kirigami? no trailing 1 or 2.

In T8586#167431, @scarlettclark wrote:

New entry for un-merged NEED assistance

Kpackage
diff --git a/debian/control b/debian/control
index 8a7a919..6d55fd3 100644

• a/debian/control +++ b/debian/control @@ -25,6 +25,7 @@ Vcs-Git: https://salsa.debian.org/qt-kde-team/kde/kpackage.git Package: kpackagetool5 Section: kde Architecture: any +Multi-Arch: foreign Depends: ${misc:Depends}, ${shlibs:Depends} Breaks: kpackagelauncherqml (<< 5.51), libkf5declarative5 (<< 5.51),
  
  I was going to merge request this upstream. But it seems wrong? that is a binary package - I thought foreign was things like docs that are platform independent. @bshah made the commit. I need backup if I am to upstream this.

Knewstuff
There is a diff in rules where we have a fix perms: @jriddell
87cab9b ("dont remove executable on script", 2017-11-09)
+
+override_dh_fixperms:
+ $(overridden_command) -X_update_all_files.sh
Is this something that can be merged into debian? If so I need the "why"

In T8586#167425, @scarlettclark wrote:

New entry for un-merged and reason why.

TO-DO
Kirigami 1 2 what the heck??
Debian seems to package this in a repo called kirigami
We package it in kirigami2 and master is all neon commits. I am not touching this. So confusing..
REASON
The kirigami issue is we package kirigami1 as well as kirigami2 while I think Debian only packages kirigami2.
You could check if the rdepends of qml-module-org-kde-kirigami really still need kirigami1 or if they can be updated and the package dropped

Syndication -
https://packaging.neon.kde.org/kde/syndication.git/log/?h=Neon/unstable_merge

This has a diff in signing keys - this should be pushed to debian?
https://packaging.neon.kde.org/kde/syndication.git/commit/?h=Neon/unstable&id=2de11348d54275afba76daba92100c3ec2ed8fac
REASON
On hold for 5.51 release was missed in debian. Inquiry is in.

Kconfigwidgets -
https://packaging.neon.kde.org/kde/kconfigwidgets.git/log/?h=Neon/unstable_merge

Incidently this has both a .manpages and the manpages are in the -data package - I think debian needs fixing here.
diff --git a/debian/libkf5configwidgets-data.install b/debian/libkf5configwidgets-data.install
index 64d9b94..1f22720 100644

• a/debian/libkf5configwidgets-data.install +++ b/debian/libkf5configwidgets-data.install @@ -1,5 +1,3 @@ etc/ usr/bin/preparetips5 usr/share/locale/* -usr/share/man/*/man1/preparetips5.1 -usr/share/man/*/man1/preparetips5.1 REASON This needs to be upstreamed to debian - WIP - sadly FTBFS
  
  Plasma-framework - https://packaging.neon.kde.org/kde/plasma-framework.git/log/?h=Neon/unstable_merge
  
  diff --git a/debian/control b/debian/control index 276d009..601397f 100644
• a/debian/control +++ b/debian/control @@ -44,6 +44,7 @@ Build-Depends: cmake (>= 3.0~), libxcb-composite0-dev, libxcb-damage0-dev, libxcb-shape0-dev, + mesa-common-dev, pkg-config, pkg-kde-tools (>= 0.15.15ubuntu1~), qtbase5-dev (>= 5.8.0~),
  
  Jonathan commit: https://packaging.neon.kde.org/kde/plasma-framework.git/commit/?h=Neon/unstable_merge&id=e5c294843de12b95fa5ca6dd33236d0c713826f2

I wonder if I merge these - should resolve the issue?

In T8586#167425, @scarlettclark wrote:

New entry for un-merged and reason why.

TO-DO
Kirigami 1 2 what the heck??
Debian seems to package this in a repo called kirigami
We package it in kirigami2 and master is all neon commits. I am not touching this. So confusing..
REASON
The kirigami issue is we package kirigami1 as well as kirigami2 while I think Debian only packages kirigami2.
You could check if the rdepends of qml-module-org-kde-kirigami really still need kirigami1 or if they can be updated and the package dropped

Still has depends -
peruse
kube
plasma-sdk
plasma-sdk