- User Since
- Sep 15 2015, 12:04 PM (165 w, 6 d)
Oh and FWIW, Nate, when there is internet the thing will finish in seconds, so this is actually tricky to test in real life unless you manually pkcon update -d; disconnect; pkcon update
This entire shebang was moved to neon-settings and is now being tested in dev/unstable.
Sat, Nov 17
Fri, Nov 16
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.
Thu, Nov 15
Can you please abandon this revision so it disappears from my read-to-review list :)
This has been landed in a global reformat.
Wed, Nov 14
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.
Mon, Nov 12
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
Tue, Nov 6
It was fixed in that it doesn't crash anymore. Due to crash handling now going through kcrash you still want to have a coreapp in every slave though.
Mon, Nov 5
It's on my todo, unfortunately I am at a sprint this week so probably nothing much happening on this until next week.
Fri, Nov 2
FWIW I now absolutely hate this being in the plasma-discover packaging and IMO should be moved to neon-settings instead. Iff we want this to be part of discover's default UX it should be solved via discover itself, not add it on via the packaging.
Wed, Oct 31
The size of the ifdef (and the therein contained code copy) isn't making me super excited. OTOH there are some 10 or 20 differences between the two if-branches, so separating it into multiple ifdefs is likely a mess as well. And @asn pointed out that doing it this way makes it easier to drop the legacy branch in the future.
Tue, Oct 30
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.
Fri, Oct 26
Thu, Oct 25
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