Let's close it, I am guessing this is a non-issue given there were no reports to the contrary
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Feb 12 2019
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.
Feb 11 2019
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.
Feb 6 2019
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 -.-
Feb 5 2019
Similarly to T10105 there is no real value in this.
Feb 4 2019
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.
Jan 27 2019
Jan 25 2019
This is kind of done
Jan 15 2019
Jan 14 2019
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
Jan 13 2019
Jan 12 2019
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
Jan 9 2019
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
Dec 8 2018
Dec 7 2018
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.
Dec 6 2018
Dec 5 2018
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 thereso 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 droppedSyndication -
https://packaging.neon.kde.org/kde/syndication.git/log/?h=Neon/unstable_mergeThis 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_mergeIncidently 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?
Nov 30 2018
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
Nov 29 2018
*Tier 4 / Porting aids*
Nov 27 2018
In T8586#167501, @jriddell wrote:when moving /etc files bump the changelog version and add a mainscript in the style of kate's debian/kate5-data.maintscript
and test to make sure, the documentation on what to do with moving conffile seems entirely lacking
Nov 22 2018
port almost done. needs jobs set up
Nov 21 2018
deployment is now automated via mgmt_seed_deploy
OTOH I suppose moving the entire shebang into a jenkins job that runs daily is easy enough to do
I do wonder if we should invest time into this without using seeds for snaps. It might be good enough to leave it as it is and then address the deployment problem when we have snap seeds.
kexi is legit, choqok was undone and fixed, drkonqi may be a bogus ignore, but I am not sure its worth bothering with what with our testing exposure being next to 0 anyway
Nov 20 2018
This has moved to neon-settings and is now using a systemd service.
Nov 16 2018
*Tier 3*
*Tier 2*
Starting a new thread for MERGED in order..
when moving /etc files bump the changelog version and add a mainscript in the style of kate's debian/kate5-data.maintscript
and test to make sure, the documentation on what to do with moving conffile seems entirely lacking
KAuth: sure merge it in and recompile the packages in reverse-build-depends libkf5auth-dev
Note the version in Breaks: libkf5auth-bin-dev (<< 5.41.0-1~) etc needs changed (add a new higher version to changelog first)
unstable, stable, release, release-lts now have appstream-generator run once a day. user, user-lts continue to do it on-publish AND in addition also once per day. also asgen is now working around bugs in meson to prevent excess rebuilds, this does by and large mean that runs are in general much faster than before.
as per usual generation is off-by-one, so only the previous published versions are in the actual archive. for unstable/stable that makes no difference since they publish multiple times a day by virtue of having new builds, for release and release-lts we may wish to run auto publishing to force the dep11 data to update.
Nov 15 2018
New entry for un-merged and reason why.
Nov 14 2018
I think we've sufficiently looked at this task to not forget the lesson learned. I sure have
I've got a prototype off the ground. This may be easily solved now.
Nov 12 2018
Matthias was kind enough to fix a major blocker for on-demand downloads. Chances are we may be able to drop the rsync entirely. That makes supporting appdata in !user repos much more achievable I think.
Oct 30 2018
Eh eh, the latter is probably easier. In that we don't have to wait for a signal we could just poll in a loop in a shell script. And since it is PreStart the service will never enter running state if the poll never succeeds. With the former one would do the same albeit through a systemd timer which means playing around with those for very little gain I'd imagine.
Service is still not too exiting because the user may not be online right away (wifi or whatever). Perhaps service + regular timer? Alternatively we could maybe write a PreStart script which blocks until internet access is available? The former is probably easier while the latter may be nicer as we could wait on a dbus signal. I am somewhat undecided here :S
In all editions.
Seems to be working as expected now.
Let's leave this then.
Oct 29 2018
Either way. But my instinct says keep the delta compared to Ubuntu minimal and just live with their bugs.
Oct 25 2018
So.
Motd calls /usr/lib/ubuntu-release-upgrader/release-upgrade-motd which looks for stamp file /var/lib/ubuntu-release-upgrader/release-upgrade-available if it exists it will simply be printed again (assuming it isn't too old), if it is not it is *always* created by running /usr/lib/ubuntu-release-upgrader/check-new-release. The outcome of check-new-release may be 'Failed to connect to HOST... Check your Internet connection or proxy settings'. This will always be the case if the user logged into a login shell with motd before internet access is available (e.g. before network.target is reached by switching to a getty super early [sddm startup is not waiting for network.target], or when on a laptop before the wifi is connected). The error will then be reported until the stamp gets too old and gets refreshed. Nothing much to be done IMO as the code involved is just a bit daft. Ideally it probably shouldn't record an error but an empty stamp so there is effectively no output instead of silly output. From a neon POV what we could do is possibly disable the motd as its arguably garbage and delaying (first) login a bit due to network IO.
Having reviewed the delta it looks largely the same. As it turns out list-missing wasn't ever enabled for kf5.pm? :O
this seems resolved?
purring like a kitten it seems. adding the list-missing argument to an invocation which already had one causes duplicated output though. should be fixed now.
Oct 24 2018
T9306 is moving ahead as a global replacement for list-missing. New game plan here is to review the original delta between us and debian and decide if we need any of the other bits.