[00:46] The installation above worked [00:46] good night everyone, see you tomorrow [02:57] As a follow-up, this is how my suggestion for an overhauled Kubuntu CD Image design looks like currently: https://i.imgur.com/6JuajGF.png [04:00] @RikMills, Yes, install worked great over wifi and the wifi connection password was retained upon reboot. The retention has not always worked in the past, but it worked today. Maybe the connection is only retained if connect during install and I typically live test before install, connect to wifi in the panel, so I suspect that's the difference... Also, my timezone was correctly detected. [06:45] (Photo, 444x141) https://irc-attachments.kde.org/MOzJlTbW/file_43206.jpg Classic LP [06:49] Classic QtWebEngine being a pain in the **** [06:50] @DarinMiller, Great. Yes, that sounds likely. [06:59] To be honest I see a thing like that for the first time. Usually it takes 3 to 7-ish hours [08:44] @X, Have you not done a build since this? https://launchpad.net/ubuntu/+source/qtwebengine-opensource-src/5.15.3+dfsg-3ubuntu1 [08:51] Ha `-j2`, I see [10:41] TZ fix works for me: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1916331/comments/4 [10:41] Launchpad bug 1916331 in ubiquity (Ubuntu Hirsute) "Cannot Select TimeZone at Install Time (Kubuntu)" [High,Fix released] [10:44] mparillo: great. thanks :) [12:23] hi everyone [12:23] RikMills: I have zsynced the daily iso and tested an installation this morning, the bug is gone already [12:24] \o/ [12:24] RikMills: anything else being urgent? [12:25] I don't think so. Thanks for taking the time :) [12:25] one million thanks for fixing it, small news from my front: [12:26] - I have been assembling a new server, the new one has 16 hard disks [12:27] - I hope to do some test rebuilds, test upgrades this afternoon [12:27] what about KA? have you experienced any bug since the last beta? [12:38] santa_: gbp-ppa didn't handle the 'v' in the newest tar here very well: https://download.kde.org/stable/plasma-wayland-protocols/ [12:38] that is about it I think [12:40] ugh [12:40] that was a mistake by the upstream dev, so should not occur much [12:41] I worked around it somehow [12:49] Hi folks [13:28] RikMills: ack, I have been thinking about it and tested a number of debian/watch modifications of plasma-wayland-protocols, none of them worked XD [13:29] I see no other way to fix this than adding a shoddy thing in the KA code lie "if source_package_name == ..." [13:30] since you mention it was a temporary mistake maybe we could simply ignore it and hope they don't add the extra '-v' in the future [13:31] yep, hopefully this is a one off thing [15:19] Santa, any reason not to update the KA code with something like: … package_name = "plasma-wayland-protocols-v1.2.1.tar.xz" … version = package_name.split('-')[-1].split('.tar')[0].replace('v','') [17:39] @DarinMiller that kind of solution would just work for that plasma-wayland-protocols package, and that style of if's is a bit like embedding ka-metadata into the code :| [17:40] also you have to take into account the problem is not the version but the tarball name [17:40] plasma-wayland-protocols is of release type "other" [17:41] therefore the tarball is downloaded with uscan, then symlinked in build-area/plasma-wayland-protocols_version.orig.tar.gz [17:42] and the build-area/ symlink would point to /plasma-wayland-protocols-1.2.1.tar.gz [17:44] while it should point to /plasma-wayland-protocols-v1.2.1.tar.gz (which is the tarball name as downloaded by uscan) [17:45] and as far as I can see there is no way to alter the tarball as downloaded by uscan [17:51] * to alter the tarball name [18:49] ah, OK makes sense.