[06:56] RAOF: hey, do you think you could check the snapd SRU (2.46.1) ? woudl be great to get it into *-proposed to help e.g. the cpc tema that needs it for their work [06:57] Sure. [06:59] mvo: I presume 2.46.1 supercedes the 2.46 already in the unapproved queue? [07:00] RAOF: correct [07:00] RAOF: thanks a lot for looking into this [07:02] Urgh. Could you do a new upload, with the combined 2.46 & 2.46.1 changelog in the .changes? [07:03] Hm. [07:03] Or maybe not. [07:04] Those changelogs are not user-friendly ;) [07:05] RAOF: *cough* that is unfortunately true [07:06] Heh. https://wiki.ubuntu.com/SnapdUpdates could do with an update! [07:07] 16.04 is not the latest stable release, and it turns out we have not one, but two LTS releases that need upgrade testing for :) [07:51] RAOF: indeed, let me look at this wiki page [07:52] RAOF: thanks for letting it into -proposed [08:58] hum, I don't understand why the proposed report lists gstreamer1.0 blocked on the spice/ppc64el autopkgtest failing today but wasn't yesterday [08:58] the test failed a week ago and gstreamer didn't change since yesterday [08:58] why did it start picking it up now? [09:03] seb128: because spice passed once against zlib/1:1.2.11.dfsg-2ubuntu2, resetting the force-reset-test [09:03] https://autopkgtest.ubuntu.com/packages/s/spice/groovy/ppc64el [09:04] ginggs, oh, ok, that would explain, thanks! [09:04] seb128: yw! [09:05] could someone from ubuntu-release bump that reset? [09:16] seb128: that's one way, but is it fixed now? i'm retrying the test you triggered, adding zlib [09:18] ginggs, I already had done that (retrying with zlib added) [09:18] but yeah, let's wait for that [09:19] ginggs, https://autopkgtest.ubuntu.com/packages/s/spice/groovy/ppc64el had one success at the bottom and I don't really see why the zlib update would fix the issue, I think it's more likely that it's just get lucky sometimes and avoid the timeout and it happened to be one of those tries [09:22] seb128: yeah, that success at the bottom is just inherited from the previous series, my test has already finished - results should appear soon [09:24] if it failed you can ask in #ubuntu-release for someone to bump the force-reset-test hint [09:25] seb128: oh and there you result appeared. sigh, the lag here is really annoying [09:30] seb128, better wait for gst* 1.18 that is now in sid= [09:30] gst-plugins* merges are a nightmare [09:31] will do 1.18 once mergeomatic catches it [09:37] LocutusOfBorg: you're aware of feature freeze yes? [09:47] bah, disconnected again [09:48] Laney, unsure if that got replied, but I did sync the new gstreamer 1.17 serie before ff, just failed to merge some components to get it migrated out of proposed and I asked LocutusOfBorg for help with the merges [09:48] seb128_: ok [09:48] Laney, you think ff is needed in that case? [09:48] btw Ken took the task of looking at all of that in the last team meeting [09:48] it's a bit of a weird situation [09:48] Ken fixed his part [09:48] so you might want to check ... [09:49] which was the failed tests [09:49] what part? [09:49] the part was "gstreamer is stuck in proposed" [09:49] the failing tests [09:49] not any random section of it :p [09:49] well I talked to him friday [09:49] I don't he realized there was more than the tests [09:49] since the by team report doesn't mention the broken binaries [09:49] ff> probably not, but depends what is in the new releases [09:49] (I've a mp up for review improving that btw) === seb128_ is now known as seb128 [09:50] Laney, well, technically the non merged plugins would need a ffe since that's an update to a new serie [09:51] but at the same time it's the same as the new GNOME, we can't release one an half finished transition... [09:54] I guess the main thing we'd want is reassurance that it's been well tested and that someone is going to take care of any issues [10:09] LocutusOfBorg, hey, since 1.18 has been uploaded then the merges are doable now [10:11] not sure why you'd want/need to wait for merge-o-matic when those are maintained in git in both Debian and Ubuntu [10:12] hopefully the latter is true, but I refuse to check and find out it's not since I stopped looking after it :p [10:39] Laney, they are maintained in git, and I update git [10:39] but the packaging has been redone from scratch [10:39] so merge is painful [10:40] and by looking at the ~10 closed bugs in 1.18, mentioning crash fixes in Debian, meh, I think its worth a look... [10:40] how can merge-o-matic do it better? [10:40] specially because the diff between 1.17.90 in proposed and 1.18 might be so little [10:40] Laney, probably it won't but meh, I'm used to it [10:41] I usually use MoM and then commit on git and upload :p [10:49] 🙈 [10:51] * xnox too [10:51] 😱 [10:51] i remember using mercurial-queues really well to do merges. [10:51] bzr merge didn't quite work for me. [10:52] and i never managed a git-based package merge yet. === didrocks999 is now known as didrocks [14:54] FYI my +1 maint shift started and I am trying to make rails 6 migrate [15:15] Laney: are you AA on a +1 by any chance? [15:15] i want to demote two packages, and remove two =) [15:16] cause that's the way my +1 maintainance rolls. [15:16] i guess i can highlight that in the status report. [15:27] seb128, sync the gst* from sid? [15:27] I'm doing based and good merges now [15:27] *good and ugly* [15:28] LocutusOfBorg, I will sync when syncpackage picks the update up, which isn't the case yet [15:28] interesting, mergeomatic picked them up [15:30] Hi tsimonq2, would appreciate your input wrt Lubuntu on this topic: [15:30] https://discourse.ubuntu.com/t/default-im-config-configuration/17136 [15:32] xnox: I'm not, but I could maybe help depending on if it's simple [15:32] if it requires some thought, punt to the status report :-) [15:35] LocutusOfBorg, I don't really understand how often and when things get available for syncing... [15:40] merge-o-matic goes off its own Debian mirror, so it can be a bit in advance of LP's view on occasion [15:40] Just depends on exact timing of Debian archive cycles etc. [15:41] LP's view is synced every six hours a little behind when the Debian archive is predicted to publishe [15:41] *publish [15:41] But it's not a particularly exact science [15:44] thanks for the details, I will retry in a bit [16:44] hello - I'm missing some historical context on the purpose of the Xorg enablement stack (xserver-xorg-hwe-18.04 in Bionic) and thought someone here might be able to help [16:44] is the Xorg enablement stack required for compatibility with the kernel enablement stack or is it purely for supporting new hardware? [16:45] in other words, has the kernel enablement stack broken something in Xorg? [17:07] tyhicks: the latter, traditionally. but these days there's less hwe specific bits in the xorg stack, maybe for amdgpu but that's it. mesa is backported as-is, so that the GA stack uses the same mesa without issues [17:14] seb128, finally looks syncable now [17:16] thanks tjaalton :) [18:01] yw :)