[11:57] Howdy folks [13:16] So now that the release frenzy is over, anybody want to pick up the cdimage.u.c theming topic? [13:25] krytarik: looks quite nice. do you have code to propose? [13:30] Yeah, and it's fine to deploy own its own. But there is also a broken favicon which is because the URL the site points to isn't valid anymore, so this would require a patch to the CD Image project on LP - which I could also do, but then it'd be better to deploy the icon directly in its assets rather than simply pointing to the Kubuntu website how it was done the last time.. [13:30] I'm gonna just pastebin the CSS for you right now though.. [13:32] not sure if the css lives in a VCS anywhere [13:33] Yeah, didn't find one either. [13:33] lubuntu might know. they changed theirs a cycle or 2 ago [13:34] * RikMills asks [13:35] otherwise I will ask the release team on Monday [13:35] Yeah, which I did too in fact, but I knew they got a repo for it to begin with. On Kubuntu I searched all across LP but couldn't find one yet. [13:46] https://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/view/head:/lib/cdimage/tree.py#L1219 - would be the CD Image part, where also the font bit should be dropped by now, and I'd the favicon URLs of the other flavors too to refer to "//" rather than a fix protocol like "http://" as currently - since with the recent enabled support for HTTPS on cdimage.u.c itself at least ... [13:46] ... (mirrors may or may not support it), there is now a mixed content issue. [13:47] right [13:48] http://paste.openstack.org/show/IGIK1bxZtn3vBCQIGpfv/ - and this is the current CSS. [13:53] And unless we find a VCS repo still with the current assets, I think we should create one, put the current ones in it first and then apply the planned changes - then we can just refer to it to deploy from. [18:10] hi everyone [18:12] RikMills: whenever I can steal you some minutes I would like to chat about the following: [18:12] 1. my marble research outcome [18:12] 2. test rebuilds [18:12] 3. kjs[embed] FTPFSes [18:13] 4. kdepim-runtime & libenet [18:13] 5. backports of frameworks and apps for hirsute [18:13] and that's it [18:13] ok [18:14] so ... whenever you have time, just give me a ping :) [18:14] ping [18:14] ok, let's go [18:15] about marble, in addition to to the 3 changes I already showed you, I also had to add qtwebengine to the libmarble-dev depends [18:16] this is needed, otherwise kreport and kphotoalbum cmake execution won't be able to find libmarble [18:16] I checked this rebuilding the packages against out latest marble in the PPA [18:16] fair enough [18:17] in addition to that, I ran photoalbum and it doesn't crash and the thing provided by marble apparently works [18:18] I have pushed the changes to git as they seem ready now, if you find any addition issue, please let me know [18:18] will do. thanks for the work :) [18:18] also note that the modification of the patch is *optional* but I did anyway since it might help to find additional issues with the packaging changes [18:19] to summarize the *needed* delta with debian is: slightly different symbols files, 2 extra lines in the debian/control [18:19] not a big tragedy in my opinion [18:20] and I think that's all for marble, move to topic 2.? [y/n] [18:21] y [18:21] I am also watching a live stream that is talking about 21.04, so my answers may be slow [18:23] no prob, about test rebuilds (this is just info): I have noticed we already have working apt repos for impish, meaning I'm going to configure my server soon to build packages for impish, before doing that I'm going to do one last test rebuild of everything this weekend [18:24] that being said, and moving to topic 3. I bet the ksj[embed] FTBFSes are going to be there [18:25] so, for these 2 my opinion is the following: [18:25] - they are not worth an SRU [18:26] - however, imho it would be convenient to have a fix for symbols in the _hirsute_archive branches, just in case we need to do an SRU or security fix of these 2 [18:26] (this way we will have the fix for symbols files already there in case we need them) [18:27] any comments about this? [18:28] push to a kubuntu_hirsute_fix branch? [18:29] so we have if needed? [18:29] hmm, not sure if having an ad-hoc branch would be the best [18:30] I don't like the archive branch to not be EXACTLY what is in the archive [18:30] well, the advantage of that approach would be that if someone (not us) prepares an SRU we would be able to sync the _archive branches [18:30] so, ok, let's have it that way [18:30] ok [18:31] are you ok with the kubuntu_hirsute_symbolsfix branch name? [18:31] yeah, that is better than my suggestion :) [18:31] alright, move to topic 4.? [y/n] [18:32] y [18:32] ok, about that, we have kdepim-runtime in orange in the status page because of our lack of libenet [18:34] I have checked neon, and they have packaged it, also when kdepim-runtime is built against this new bd, it produces some extra files, so they also adjusted the *.install files [18:34] that being said, I would skip this b-d for a while and whenever I have time I could investigate the libenet packaging [18:35] I have the impression that the copyright file will need a couple of small adjustments if we want it to pass our upload queue [18:36] also I would need to check what's the deal with its ABI stability, and a proper packaging strategy with regarding to that [18:37] so, well, this 4. item is mostly info :) [18:37] I don't see anything about libenet in the kdepim-runtime build log? [18:37] our kdepim-runtime? [18:37] yes [18:37] 20.04.0 ? [18:38] 21.04.0 [18:38] yes [18:38] oh, sorry, I mistyped the name [18:38] it's etebase/libetebase [18:39] Ok. got that! [18:39] ok. back burner for now then [18:39] on to 5. I think [18:40] ok, so about that: I have been correcting a number of oranges in the status pages of apps [18:41] thanks [18:41] while it's not 100% green, in my opinion we could move the fw 5.81 and apps 21.04.0 to backports-landing (if you didn't already) [18:42] I have tested in a VM, and I started kmail with a fake testing account [18:42] 5.81 is already in backports. mamarley and DarinMiller confirmed it worked well [18:43] (Photo, 1280x683) https://irc-attachments.kde.org/N0pP6FjN/file_43417.jpg [18:43] I have just not shouted about it yet [18:44] ok, so let's copy apps to backports-landing, a bit later to backports and if you or someone else have time, put it on news of kubuntu.org? [18:45] santa_: https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/backports/+packages?field.name_filter=&field.status_filter=published&field.series_filter=hirsute [18:45] already there. I was planning to add a new item in the next few days [18:45] *news item [18:46] apps 21.04 we could copy to landing, but I might prefer to wait for 21.04.1 bugfix before going to actual backports [18:47] RikMills: So short of still finding an old repo for it, I've just created under my own user for now, along with which should be merged first of course. If you agree to the changes pertaining to Kubuntu, I'll file an MP for the latter. Then once ... [18:47] ... that's done, we can ask people to deploy the updated assets to cdimage.u.c and remove the old ones from releases.u.c - there is a cosmetical change on the Lubuntu ones that also should be deployed then. [18:48] fine for me [18:49] RikMills: ok, I will proceed now with the copy to backports-landing if you agree [18:49] RikMills: Ok, then I'm gonna file the MP now. [18:49] santa_: ack [18:49] krytarik: thanks [18:52] RikMills: Oh, would you like to copy the cdimage-css repo to under the ~kubuntu-website team first, so that it looks more approved? [18:53] Because I'd link to both it and the Lubuntu one in the MP then. [18:54] don't think it matters, but whatever if you like ;) [18:55] I'd prefer to avoid any questions regarding its approval, yes. XD [18:55] Also, it should end up there anyway.. [20:01] RikMills: Either that or I'm afraid I'm gonna have to add you as a reviewer.. >_<