[04:13] xnox: huh! The Mir symbols mismatch is an interesting one! [04:14] xnox: I think it's plausibly a bug/missing feature in dpkg-gensymbols. [04:14] But it's also weird behaviour by the linker. [04:17] With LTO enabled, the linker emits debug symbols (but not the function symbols) for some otherwise-unexported symbols. [04:18] dpkg-gensymbols then complains that we're introducing new symbols. [04:20] But you can't actually *link* against those symbols; they're just the debug info. So they're irrelevant for the symbols file. [04:20] Hmmmm [04:54] And, of course, dh_strip gets them out of the DSO *anyway*, and the problem is only that the `check-miral-symbols` target gets run before `dh_strip` is. [06:12] infinity: hey, good morning, sorry for not getting back last night, real life interfered :/ [06:13] infinity: I tried to reproduce in various ways yesterday but no luck, I try harder now [06:40] jibel: fwiw, I can reproduce it now with both snapd 2.33 and 2.34 :/ [06:40] jibel: we are looking into it [06:47] jibel: after a bit of poking I think this is "just" a side-effect of the seed order issue [06:47] jibel: i.e. once the seed order is correct and the initial snap seeding works then gedit should install again [08:59] Laney, good morning, quick question: if gst-plugins-good1.0 builds correctly, does this mean I can sync gst-plugins-base? [08:59] see https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa for progresses :p [09:04] LocutusOfBorg: No, we have a change in -good to keep the qt5 stuff on armhf which requires that change in -base. [09:04] If you wanted to, you could check if all of those changes can be dropped (if the current mesa is fixed) [09:04] https://github.com/KhronosGroup/OpenGL-Registry/issues/162 this one was closed [09:10] are you doing the point release update? [09:25] RAOF[m], indeed the symbols to me looked weird. [09:39] Laney, I'm taking wrt cosmic, and the fact that we need to merge/sync gst... [09:39] I know you are [09:40] the -base plugin (new version) might have fixed that, that was the origin of the question [09:40] It'll be a fix in the headers that come with mesa [09:40] mmm they might have fixed in the plugin... [09:40] -#ifdef USE_EGL_RPI [09:40] +#if !GST_GL_HAVE_EGLUINT64KHR [09:40] typedef khronos_uint64_t EGLuint64KHR; [09:40] this is what I'm seeing in the diff [09:41] maybe they workarounded it, without having to wait for mesa [09:41] so, this is the question: can I upload a sync if -good builds on arm*? [09:41] (this requires stealing your merge btw) [09:42] no, you have to keep my reverts in there [09:43] if it builds with the synced base and those reverts, that's the good state [09:44] (there -> -good) [09:46] Laney, I was talking about syncing base, I know the good needs a merge (and yes, here I kept the revert of course) [09:47] ok then [09:47] and it failed to build, so can I merge both? :) [09:48] tjaalton, mesa merge ping :p [09:48] sure, and -bad plz [09:48] if you could use the git repositories that would make me happy [09:49] I will [09:51] not sure newest mesa is fixed yet [09:51] https://salsa.debian.org/xorg-team/lib/mesa/blob/debian-unstable/include/GL/glext.h#L468 should be khronos_ssize_t etc [09:53] according to the debian bug seems not [09:53] I fail to see pull requests... [09:54] xnox: they're *meant* to be local:*'d away in the linker script (and, indeed, the actual text of the functions *is* not in the DSO), so it's *additionally* a ld.bfd bug. Which I'll file tomorrow. [09:54] I dunno what the process for those headers getting from khronos into mesa is; hopefully there is one [10:15] LocutusOfBorg: it'd be better if you would git merge properly rather than import-dsc [10:16] up until now those branches shared proper history with debian [10:18] oh... ok [10:18] should I force push? [10:19] * Laney looks the other way :-) [10:19] (yes, it's probably not been too long) [10:24] Laney, I don't get why you should look anywhere, looks like the history has never been pushed remotely [10:25] what? [10:26] the remote git repository is "clean" :) [10:26] * LocutusOfBorg feels dirty, as much as the remote is now clean [10:27] now I have time to properly do things... [10:27] in order to do it, I should: git merge debian/upstream pristine-tar and master, and then apply changes on top, right? [10:29] right [10:29] well upstream and pristine-tar will just be the same as what debian has, no commits there [10:29] you just push those branches and the upstream/xxx tag to launchpad [10:30] for the packaging branch, git merge the tag, which should keep our delta (may be some conflicts) [10:30] then check the various diffs [10:30] ack [10:30] will do after lunch maybe :D [10:35] Laney, can you please double-check? [10:36] LocutusOfBorg: ok, where should I look? [10:38] https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gst-plugins-base1.0?h=master [10:38] and so on [10:38] I did base good and bad [10:38] ok, I would expect pristine-tar to be 6f933d105fc6d371a55bf516eab60725fac43861 and upstream to be 248418e33dcd27b99493cc56cc92872d662db276 [10:38] for -base [10:39] and they are? [10:39] https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gst-plugins-base1.0/log/?h=pristine-tar [10:39] let me check [10:40] looks good! [10:41] nice thanks! probably the force-push messed up a little bit the graphical page, it will refresh in some hours hopefully [10:41] then gbp buildpackage --git-tag-only [10:41] should give you the ubuntu/XXX tag to push once it's uploaded [10:41] I did that already [10:42] except for the good, because gbp.conf was badly set https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gst-plugins-good1.0/commit/?id=8cf9b8fc1672cba9ad6690272f97f6dfa6c82f6f [10:42] I fixed but won't upload just because of that change [10:42] thx, you can make the tag manually [10:43] I think I only started using ubuntu/ tags on those repositories recently [10:45] it is already tagged as debian/1.14.2-1ubuntu1 [10:45] so... ok lets copy the tag [10:45] :3 [10:46] doesn't matter too much though [10:47] it matters, because I did in a bash loop the following "git diff debian/1.14.2-1 ubuntu/1.14.2-1ubuntu1" [10:47] and it failed :p [10:47] so, more automation with that change! [10:47] heh [12:39] LocutusOfBorg: next week when I'm back === zlib_is_awesome is now known as zlib_license_is_ === zlib_license_is_ is now known as zlibBetterThanMI === zlibBetterThanMI is now known as zlibBetterThnMIT === nOOb__ is now known as LargePrime [12:58] sure thanks themill [12:59] s/themill/tjalton [12:59] :) [12:59] 1 out of 7 === plars_ is now known as plars [14:30] sil2100, hi, I have an implementation for the ubuntu-image changes to be able to use a roorfs instead of lb: https://github.com/CanonicalLtd/ubuntu-image/pull/155 [14:30] sil2100, there are probably some tests missing, but it would be good if you can take a look toi give thumbs up/down to the general approach [14:45] abeato: sure, but only after the point-releases [14:45] Since we're busy with those right now [14:46] Thanks! [15:03] sil2100, sure, np === jdstrand_ is now known as jdstrand [17:15] Laney, I don't really understand the new gl failure for plugins-good... any hint? [17:47] jamespage: doko_ : fyi the py3.7 threading deadlock has been narrowed down to monkeypatching of stdlib thread modules combined with use of ThreadPoolExecutor. more details at: https://bugs.python.org/issue34173 [18:41] infinity: just in case you don't know already - your seed.yaml reorder workaround works and snap install gedit now works as expected as well [20:37] https://bugs.launchpad.net/bugs/1783363 [20:37] Launchpad bug 1783363 in gnome-shell (Ubuntu) "Use of activities in GNOME Shell 3.28.3 prohibits applications from being displayed" [Undecided,Confirmed] [23:56] mwhudson: Hrm, did the retry not fix it?