[06:56] <mvo> 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] <RAOF> Sure.
[06:59] <RAOF> mvo: I presume 2.46.1 supercedes the 2.46 already in the unapproved queue?
[07:00] <mvo> RAOF: correct
[07:00] <mvo> RAOF: thanks a lot for looking into this
[07:02] <RAOF> Urgh. Could you do a new upload, with the combined 2.46 & 2.46.1 changelog in the .changes?
[07:03] <RAOF> Hm.
[07:03] <RAOF> Or maybe not.
[07:04] <RAOF> Those changelogs are not user-friendly ;)
[07:05] <mvo> RAOF: *cough* that is unfortunately true
[07:06] <RAOF> Heh. https://wiki.ubuntu.com/SnapdUpdates could do with an update!
[07:07] <RAOF> 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] <mvo> RAOF: indeed, let me look at this wiki page
[07:52] <mvo> RAOF: thanks for letting it into -proposed
[08:58] <seb128> 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] <seb128> the test failed a week ago and gstreamer didn't change since yesterday
[08:58] <seb128> why did it start picking it up now?
[09:03] <ginggs> seb128: because spice passed once against zlib/1:1.2.11.dfsg-2ubuntu2, resetting the force-reset-test
[09:03] <ginggs> https://autopkgtest.ubuntu.com/packages/s/spice/groovy/ppc64el
[09:04] <seb128> ginggs, oh, ok, that would explain, thanks!
[09:04] <ginggs> seb128: yw!
[09:05] <seb128> could someone from ubuntu-release bump that reset?
[09:16] <ginggs> seb128: that's one way, but is it fixed now? i'm retrying the test you triggered, adding zlib
[09:18] <seb128> ginggs, I already had done that (retrying with zlib added)
[09:18] <seb128> but yeah, let's wait for that
[09:19] <seb128> 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] <ginggs> 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] <ginggs> if it failed you can ask in #ubuntu-release for someone to bump the force-reset-test hint
[09:25] <ginggs> seb128: oh and there you result appeared.  sigh, the lag here is really annoying
[09:30] <LocutusOfBorg> seb128, better wait for gst* 1.18 that is now in sid=
[09:30] <LocutusOfBorg> gst-plugins* merges are a nightmare
[09:31] <LocutusOfBorg> will do 1.18 once mergeomatic catches it
[09:37] <Laney> LocutusOfBorg: you're aware of feature freeze yes?
[09:47] <seb128_> bah, disconnected again
[09:48] <seb128_> 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] <Laney> seb128_: ok
[09:48] <seb128_> Laney, you think ff is needed in that case?
[09:48] <Laney> btw Ken took the task of looking at all of that in the last team meeting
[09:48] <seb128_> it's a bit of a weird situation
[09:48] <seb128_> Ken fixed his part
[09:48] <Laney> so you might want to check ...
[09:49] <seb128_> which was the failed tests
[09:49] <Laney> what part?
[09:49] <Laney> the part was "gstreamer is stuck in proposed"
[09:49] <seb128_> the failing tests
[09:49] <Laney> not any random section of it :p
[09:49] <seb128_> well I talked to him friday
[09:49] <seb128_> I don't he realized there was more than the tests
[09:49] <seb128_> since the by team report doesn't mention the broken binaries
[09:49] <Laney> ff> probably not, but depends what is in the new releases
[09:49] <seb128_> (I've a mp up for review improving that btw)
[09:50] <seb128> Laney, well, technically the non merged plugins would need a ffe since that's an update to a new serie
[09:51] <seb128> but at the same time it's the same as the new GNOME, we can't release one an half finished transition...
[09:54] <Laney> 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] <seb128> LocutusOfBorg, hey, since 1.18 has been uploaded then the merges are doable now
[10:11] <Laney> 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] <Laney> 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] <LocutusOfBorg> Laney, they are maintained in git, and I update git
[10:39] <LocutusOfBorg> but the packaging has been redone from scratch
[10:39] <LocutusOfBorg> so merge is painful
[10:40] <LocutusOfBorg> 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] <Laney> how can merge-o-matic do it better?
[10:40] <LocutusOfBorg> specially because the diff between 1.17.90 in proposed and 1.18 might be so little
[10:40] <LocutusOfBorg> Laney, probably it won't but meh, I'm used to it
[10:41] <LocutusOfBorg> I usually use MoM and then commit on git and upload :p
[10:49] <Laney> 🙈
[10:51]  * xnox too
[10:51] <Laney> 😱
[10:51] <xnox> i remember using mercurial-queues really well to do merges.
[10:51] <xnox> bzr merge didn't quite work for me.
[10:52] <xnox> and i never managed a git-based package merge yet.
[14:54] <kanashiro> FYI my +1 maint shift started and I am trying to make rails 6 migrate
[15:15] <xnox> Laney:  are you AA on a +1 by any chance?
[15:15] <xnox> i want to demote two packages, and remove two =)
[15:16] <xnox> cause that's the way my +1 maintainance rolls.
[15:16] <xnox> i guess i can highlight that in the status report.
[15:27] <LocutusOfBorg> seb128, sync the gst* from sid?
[15:27] <LocutusOfBorg> I'm doing based and good merges now
[15:27] <LocutusOfBorg> *good and ugly*
[15:28] <seb128> LocutusOfBorg, I will sync when syncpackage picks the update up, which isn't the case yet
[15:28] <LocutusOfBorg> interesting, mergeomatic picked them up
[15:30] <GunnarHj> Hi tsimonq2, would appreciate your input wrt Lubuntu on this topic:
[15:30] <GunnarHj> https://discourse.ubuntu.com/t/default-im-config-configuration/17136
[15:32] <Laney> xnox: I'm not, but I could maybe help depending on if it's simple
[15:32] <Laney> if it requires some thought, punt to the status report :-)
[15:35] <seb128> LocutusOfBorg, I don't really understand how often and when things get available for syncing...
[15:40] <cjwatson> 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] <cjwatson> Just depends on exact timing of Debian archive cycles etc.
[15:41] <cjwatson> LP's view is synced every six hours a little behind when the Debian archive is predicted to publishe
[15:41] <cjwatson> *publish
[15:41] <cjwatson> But it's not a particularly exact science
[15:44] <seb128> thanks for the details, I will retry in a bit
[16:44] <tyhicks> 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] <tyhicks> is the Xorg enablement stack required for compatibility with the kernel enablement stack or is it purely for supporting new hardware?
[16:45] <tyhicks> in other words, has the kernel enablement stack broken something in Xorg?
[17:07] <tjaalton> 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] <LocutusOfBorg> seb128, finally looks syncable now
[17:16] <tyhicks> thanks tjaalton :)
[18:01] <tjaalton> yw :)