| 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:56 |
|---|---|---|
| RAOF | Sure. | 06:57 |
| RAOF | mvo: I presume 2.46.1 supercedes the 2.46 already in the unapproved queue? | 06:59 |
| mvo | RAOF: correct | 07:00 |
| mvo | RAOF: thanks a lot for looking into this | 07:00 |
| RAOF | Urgh. Could you do a new upload, with the combined 2.46 & 2.46.1 changelog in the .changes? | 07:02 |
| RAOF | Hm. | 07:03 |
| RAOF | Or maybe not. | 07:03 |
| RAOF | Those changelogs are not user-friendly ;) | 07:04 |
| mvo | RAOF: *cough* that is unfortunately true | 07:05 |
| RAOF | Heh. https://wiki.ubuntu.com/SnapdUpdates could do with an update! | 07:06 |
| 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:07 |
| mvo | RAOF: indeed, let me look at this wiki page | 07:51 |
| mvo | RAOF: thanks for letting it into -proposed | 07:52 |
| 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? | 08:58 |
| 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:03 |
| seb128 | ginggs, oh, ok, that would explain, thanks! | 09:04 |
| ginggs | seb128: yw! | 09:04 |
| seb128 | could someone from ubuntu-release bump that reset? | 09:05 |
| ginggs | seb128: that's one way, but is it fixed now? i'm retrying the test you triggered, adding zlib | 09:16 |
| seb128 | ginggs, I already had done that (retrying with zlib added) | 09:18 |
| seb128 | but yeah, let's wait for that | 09:18 |
| 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:19 |
| 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:22 |
| ginggs | if it failed you can ask in #ubuntu-release for someone to bump the force-reset-test hint | 09:24 |
| ginggs | seb128: oh and there you result appeared. sigh, the lag here is really annoying | 09:25 |
| LocutusOfBorg | seb128, better wait for gst* 1.18 that is now in sid= | 09:30 |
| LocutusOfBorg | gst-plugins* merges are a nightmare | 09:30 |
| LocutusOfBorg | will do 1.18 once mergeomatic catches it | 09:31 |
| Laney | LocutusOfBorg: you're aware of feature freeze yes? | 09:37 |
| seb128_ | bah, disconnected again | 09:47 |
| 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:48 |
| 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:49 |
| === seb128_ is now known as seb128 | ||
| seb128 | Laney, well, technically the non merged plugins would need a ffe since that's an update to a new serie | 09:50 |
| seb128 | but at the same time it's the same as the new GNOME, we can't release one an half finished transition... | 09:51 |
| 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 | 09:54 |
| seb128 | LocutusOfBorg, hey, since 1.18 has been uploaded then the merges are doable now | 10:09 |
| 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:11 |
| 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:12 |
| 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:39 |
| 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:40 |
| LocutusOfBorg | I usually use MoM and then commit on git and upload :p | 10:41 |
| Laney | 🙈 | 10:49 |
| * 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:51 |
| xnox | and i never managed a git-based package merge yet. | 10:52 |
| === didrocks999 is now known as didrocks | ||
| kanashiro | FYI my +1 maint shift started and I am trying to make rails 6 migrate | 14:54 |
| xnox | Laney: are you AA on a +1 by any chance? | 15:15 |
| xnox | i want to demote two packages, and remove two =) | 15:15 |
| xnox | cause that's the way my +1 maintainance rolls. | 15:16 |
| xnox | i guess i can highlight that in the status report. | 15:16 |
| 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:27 |
| 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:28 |
| 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:30 |
| 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:32 |
| seb128 | LocutusOfBorg, I don't really understand how often and when things get available for syncing... | 15:35 |
| 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:40 |
| 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:41 |
| seb128 | thanks for the details, I will retry in a bit | 15: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:44 |
| tyhicks | in other words, has the kernel enablement stack broken something in Xorg? | 16:45 |
| 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:07 |
| LocutusOfBorg | seb128, finally looks syncable now | 17:14 |
| tyhicks | thanks tjaalton :) | 17:16 |
| tjaalton | yw :) | 18:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!