yeah, so, I think I'll convert this to a systemd service. possibly have the service disable itself so it doesn't needlessly get looked at after it ran once. also, that way the service won't add the repo back if the user manually removed it for whatever reason (i.e. we have a record of if we added it automatically or not - the disabledness)

The distro gets ignored by the builders, it's only the version number it uses

Ok - I am seeing this enough to warrant a comment - I am seeing quite a few changelog entries for 5.51 release as xenial - I thought unstable was bionic?

So far all are failing the lintcmake test. I need help as I can't sort out what needs to be done to fix them. Help please.

The kirigami issue is we package kirigami1 as well as kirigami2 while I think Debian only packages kirigami2.

looking good thus far
kcoreaddons - yes kill our change no longer needed
Kidletime - well Debian is right unless there's some reason not to but moving /etc conffiles between packages is bloody faffy, see man dpkg-maintscript-helper and see if you can work it out
Kjs - yes scrap that patch it's not needed
you don't need to merge in our changelog additions except the top one, e.g. kplotting doesn't need all our changelog additions except the 5.51.0 one

pushed.
Looks like there is a que. I am starving and must eat. Will check on it when I get back.

yes, you can look at Neon/unstable and see what is needs to be, looks like 5.51.0-0neon

Ready to merge, but when you say good version number... this is probably not one? or is it? extra-cmake-modules (5.50.0-1~) UNRELEASED; urgency=medium I think unstable is 5.51?

If you added it I expect you had a good reason, just merge it into Neon/unstable_merge and merge that into Neon/unstable and build

Well it seems I made this commit. 3b22cbd ("Add qttools5-dev-tools to ECM for ECMPoQmTools.cmake", 2017-12-08)
It is not brought in by shlibs:Depends so unless something changed in ECMPlQmlTools.cmake I think it may still be needed? I think this requires more investigation.

check the changelog and see if you can work out where the change came from and which we want, but I expect it's fine to go with what's in master. go ahead and merge into Neon/unstable when done.

In T8586#164165, @jriddell wrote:

Diff compared to master is:

-Depends: qttools5-dev-tools, ${misc:Depends}, ${shlibs:Depends}
+Depends: ${misc:Depends}, ${shlibs:Depends}

any reason for that?

Diff compared to master is:

ECM https://packaging.neon.kde.org/kde/extra-cmake-modules.git/commit/?h=Neon/unstable_merge

This is working now when updating

no offending repos

this is blocked by CI not being busy. I do have a script for it though

• 3dparty/sddm

backports-xenial/pyqt5

• extras/calamares
• forks/base-files (massively conflicting, assuming no merge needed)
• forks/live-build (massively conflicting, assuming no merge needed)
• kde/plasma-discover
• neon/seeds (partial merge of release & update run & merge into stable/unstable [ was missing calendar addons ]; unstable not merged as no worthwhile changes)
• qt/qtchooser

Can't QA because our branches are inconsistent crap still.

needs some testing in unstable before merging into releases

shrunk from 200G to 40G

The results of the motd check are cached, which may be why it's hard to reproduce because the second call probably would use the no-update-found cached result (which was produced by being unable to connect to releases.neon). I think removing the feature is not called for here given it is cached, which leaves us with debugging why it goes wrong. That may or may not be easier to do knowing that results are cached. I've also had a quick look at the actual checker code and I can't see it setting a short time, so its probably not a http timeout that is the problem here.

This has been resolved. Casper is now disabling kwallet which prevents plasma-nm from using kwallet. a casual code review suggests that applications using kwallet generally will and are expected to handle this correctly (to them it looks like kwallet is not available) and work correctly. I've tested plasma-nm and kio/sftp and they both work as expected. This means passwords are potentially not stored or stored unencrypted, this shouldn't be a huge deal though as the live sessions are not persistent

bionic uses Neon/unstable while xenial uses Neon/unstable_xenial so that seems to work fine
https://build.neon.kde.org/job/bionic_unstable_kde_extra-cmake-modules/configure
https://build.neon.kde.org/job/xenial_unstable_kde_extra-cmake-modules/configure

don't merge the changelogs, we don't care about them, just use whatever debian has and make sure the top entry has a good version number. git merge -Xtheirs may well be what you want

In T8586#163003, @scarlettclark wrote:

ok did all that and not seeing jobs still. But on another note - the first one I tried I have changelog madness. How do we want to handle those?

ok did all that and not seeing jobs still. But on another note - the first one I tried I have changelog madness. How do we want to handle those?

Oh. I totally misunderstood the original instructions. Re-working my script. Thanks.

Each of the branches
Neon/release
Neon/releaes-lts
Neon/stable
Neon/unstable

Ok, branches created. Ran job_updater and.. no jobs. I missed a step somewhere :) Is there a config file I need to update?

https://packaging.neon.kde.org/kde/plasma-discover.git/commit/?id=f7929ece16fb73bdb05103dfbdefe9ad11213cd7
snap backend now default install

https://packaging.neon.kde.org/kde/plasma-discover.git/commit/?id=f7929ece16fb73bdb05103dfbdefe9ad11213cd7
discover backend now default

quick fix while we wait in distro-release-notifier
https://phabricator.kde.org/T9789

Now that bionic is out we can merge our repos with Debian again and
try to minimise the diff. Place to start would be tier 0 and tier 1
frameworks repos

appdata in unstable is 4 months old and doesn't get updated. fix it

make it hard Dep of discover or merge into main discover packages both flatpak and snap backends

Do this in post install discover so Flatpaks are ready to install
https://flatpak.org/setup/Ubuntu/

Should be solved. All repos that need it now have bionic branches for all build variants.

kexi cmake-ignore needs comments on the BUILD_* vars, they are cmake options but kexi raises them as features that aren't enabled (BS, but oh well)

Doesn't seem to actually do anything negative, simply fails to show the update message in the MOTD