User1: rbasak: Hey there! You're probably EOD a while ago, but when you have a chance, could you take a look at bug 1641912? It's been verification-done for more than a week. ;)
User2: bug 1641912 in gtk+2.0 (Ubuntu Zesty) "Please backport two recent-manager patches" [Critical,Fix committed] https://launchpad.net/bugs/1641912
User1: (or any other member of the SRU team for that matter ^^^^^^)
User3: User1 there's an autopkgtest regression listed on http://people.canonical.com/~ubuntu-archive/pending-sru.html which should be resolved
User4: doku: with latest GCC7 I am getting failures building 2 packages against hunspell. e.g. http://paste.ubuntu.com/25282312/
User5: hi, is this the right place to ask about https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1697450 ?
User2: Launchpad bug 1697450 in ubiquity (Ubuntu) "Installer freezes at session startup" [Undecided,New]
User6: jbicha, can you please ping upstream about geary/s390x?
User6: it seems a showstopper for gmime
User7: User1 I'll be available for Qt excuses retry dance when I'm around, since it doesn't distract me from work really much to click those buttons :) but you'll need probably release team again to ignore bunch of KDE packages as usual. anyway, congrats on the proposed upload!
User7: User8 dear one of the just four memebers of ubuntu-mir, if you have time before feature freeze please check bug #1708428 MIR request - the HFST, Giellatekno etc people would be happy to get the spell-checking support into next Ubuntu LTS too similar to Debian 9.0, and 17.10 would be good time for it to be enabled
User2: bug 1708428 in hfst-ospell (Ubuntu) "[MIR] hfst-ospell" [Undecided,New] https://launchpad.net/bugs/1708428
User8: User7 unsure I'll have time before FF but I'll have a look afterwards if nobody beats me to it! Thanks for looking into this :)
User7: no problem, and thanks for trying! ;)
User8: yw! :-)
User4: enchant will FTBFS against new hspell 1.4-1 if it is rebuilt http://paste.ubuntu.com/25283249/
User4: seeded on most desktops AFAIK
User4: KDE's sonnet and and kde4libs also fail in the same way if built with it
User4: doko: apologies. thought that was GCC7, bit seems not
User9: User6 I filed https://bugzilla.gnome.org/show_bug.cgi?id=783882
User2: Gnome bug 783882 in build "geary fails to build on s390x" [Normal,New]
User6: thanks!
User9: but sometimes we just remove desktop apps on s390xâ¦
User6: so will you ask to remove it?
User9: User6 since you're working on that transition, could you? the bug I filed upstream is ~2 months old
User6: I'm wondering about adding a cast
User8: xnox: hey, are you looking at systemd migrating to the release pocket? It seems you fixed some tests that will help glib migrating as well (and others depending on it)
User6: and also some testsuite hangs :)
User8: indeed
User6: well, systemd fails testsuite against itself
User10: Desktop team, User11 is this a mistake? "Ubuntu 16.04.3 LTS will be supported for 5 years for Ubuntu Desktop". It's the .3 bit that I'm asking about, as it should be 6 months for each backported stack https://wiki.ubuntu.com/XenialXerus/ReleaseNotes
User10: ... and I used the wrong room
User11: tseliot, just looks like an over-zealous search and replace
User10: User11 yes, that's what I thought too, thanks
User11: checking the logs
User10: ok, I'll wait
User11: tseliot, hrm, I cant seem to log in for some reason... bear with me
User11: tseliot, something not right his sso login to the wiki by the looks of things.  If you are able to edit, please do, otherwise I'll try again later
User11: s/his/this
User11: er, with even.  meh
User10: User11 ok, let me try that
User10: User11 shall I just replace 16.04.3 with 16.04, or shall I say it will be supported for 6 months?
User12: 16.04.3 is the point release version, it has nothing to do with the HWE stack
User12: it's supported by updating to the next stack
User10: User12 but then, when you get a newer stack, it won't be 16.04.3 any more, it will be .4
User12: I'm running 16.04.3 and I don't have the HWE stack
User10: User12 what is it that makes it 16.04.3 then?
User12: new installation media that includes the latest updates, that's all
User9: User6 thanks for fixing geary :)
User12: I don't think it's important to note that certain packages will only get supported for 6 months if they will be automatically replaced without anything special the user needs to do
 * mdeslaur shrugs
User12: the blurb can certainly be changed to "16.04" instead of "16.04.3"
User10: User12 it's all fine, except for people running or developing binary drivers. If the X ABI changes, or the kernel breaks, the binaries won't work any more, and avoiding to upgrade to the new stack will lead to a dead end (security issues, etc.)
User10: this was my main point
User10: it's a bit misleading in that specific case
User10: I corrected that
User1: User3 I've already asked about it ;) https://irclogs.ubuntu.com/2017/08/03/%23ubuntu-release.html#t10:15
User1: User7 ok :D
User6: tsimonq2, please fix qtwebengine
User6: jbicha, I hope to have fixed it
User6: I'm not sure
User1: User6 sure
User1: User6 Although didn't slangasek say to hold off on 5.9 for QtWebEngine until the GCC transition was done or something?
User6: i386 and amd64 were fine
User6: tsimonq2, perl, gcc, binutils, kernel and so on migrated 10 hours ago
User1: User6 :D
User6: the excuses file went from 11Mb to ~5
 * LocutusOfBorg my firefox is happier
User1: hahahahahahahahahahahaha seriously? :D
 * tsimonq2 's firefox is also quite a bit happier <3
User6: https://launchpad.net/ubuntu/+source/qtwebengine-opensource-src/5.9.1+dfsg-2build1/+build/13223030
User6: please also take the ball to fix arm64
User6: even if the build went successful at the end, not sure why
User6: well, please also fix amd64 and i386
User6: you have logs for everything, and they match with the ongoing build2 build
User6: because they were on the same toolchain (removed for other reasons)
User1: ic
User1: ok
User1: User6 side note, while I'm getting my coffee, could you help me look into why ben isn't migrating? I think it depends on something that needs a piuparts pass but doesn't have one
User6: forget about ben
User6: http://people.canonical.com/~ubuntu-archive/transitions/html/ocaml.html
User6: this is why
User6: maybe xnox slangasek ^^
User6: there is some ocaml arm64 regression out there
User1: User6 ack
 * tsimonq2 is caffeinated
User4: LocutusOfBorg tsimonq2 what is wrong with? https://launchpad.net/ubuntu/+source/qtwebengine-opensource-src/5.9.1+dfsg-2build2
User1: User4 symbols
User1: User4 working on it atm
User4: ah
User1: User6 Your fixed qtwebengine: http://people.ubuntu.com/~tsimonq2/packages/qtwebengine-opensource-src_5.9.1+dfsg-2ubuntu1.dsc :D (should be done uploading in a couple of mins)
User1: RIP my connection :P
User6: tsimonq2, dpkg-buildpackage -S -d
User6: not -sa
User1: ok
User1: Lintian takes a looooooooong time with this large of a package...
User6: no need to run lintian
User1: User6 debuild does it automatically
User6: they are just symbols
User1: User6 And it's uploaded already, same URL
User1: I know
User6: it does *after* having generated the tarballs I guess
User6: so you can ctrl+c it
User1: ok well it's done now :P
User6: also uploaded :p
User1: :D
User1: Thanks!
User6: jbicha, do you feel openbox syncy?
User6: it is not really a no-change sync, you added some newer split?
User6: I'm talking about "org.gnome.SettingsDaemon.XRANDR"
User9: User6 go ahead and sync, I want the 3.26 compatibility in Ubuntu
User6: syncd!
User6: ta
User13: tsimonq2, thanks for qtwebengine upload, looks like it should fix some autopkgtest failures
User6: hopefully
User6: I also retried some of them
User6: due to network failures
User1: User13 You're welcome :)
User13: LocutusOfBorg, thanks to you too :)
User6: we will have a clear picture in 24h
User6: but at least 20 packages seems to need fixes
User1: User6 Mhhhh, KDE packages just like to break their autopkgtests :P
User1: User4 ^
User1: He knows :P
User6: yep, some of k* and libk* needs fixes
User4: they do!
User6: I'm worried about the failures on some-arch-but-not-others
User6: for now, I don't see arch-specific regressions in qt
User6: e.g. armhf needs udev/systemd fixes
User6: or retried
User6: *s, while some amd64 were just faster and failed because of qtwebengine
User6: once it is in place we might do a retry of all of them
User1: User6 we can just completely ignore packages that depend on qtwebengine that fail on s390x or ppc64el because QtWebEgnine simply will not build on those arches (not something we can control, upstream thing)
User1: We should fix the failures on the other arches, but that's a special case
User6: (probably against proposed, since this seems to be a lock-in transition that is not always retro-compatible)
User1: User6 It is
User6: tsimonq2, yes, we should get them removed into artful, and testsuite will be ignore automagically IIRC
User4: yes, tests run without that are doomed for trouble
User1: Yeahp.
User6: maybe we can rerun all the tests against a fast architecture, like ppc64el and elsewhere in case we see it "fixes"the issue
 * acheronuk peers at QtWebEngine
User6: to avoid bothering the infra with uselesss rebuilds
User4: building.......
User9: User6 you're going to have lots of autopkgtest failures from dh-acc, see my comments in #ubuntu-release
User6: lol I answered that some seconds ago
User3: User1 ah, so infinity had told you we didn't need to hint the autopkgtest regressions for gtk+2.0... he and I have a vigorous difference of opinion there, then :)  they should be hinted so that you don't have to chase multiple SRU team members around with copies of IRC logs ;)
User1: User3 fair :)
User1: User9 Mind if I steal your yelp-tools merge?
User6: jbicha, abi should be fixed
User1: oooooooooooooh, LocutusOfBorg and acheronuk, looks like QtWebEngine might be done building!
User1: Just needs an Archive Admin now to approve binaries.
User6: not so fast
User4: arm* is still building (no surprise)
User6: still needs arm*
User6: exactly
User1: ah ok
User14: need some advice on what to do with LP: #1706284 At the moment i've got it at "In Progress" , but no-one else has had the chance to reproduce it, and I've attached all the debdiffs and patches to it that fixes the issue, so what status do i set it to?
User2: Launchpad bug 1706284 in sssd (Ubuntu) "sssd fails to Update PTR if any A record update fails." [Undecided,In progress] https://launchpad.net/bugs/1706284
User15: User16 ok, uploaded a new mesa to xenial that adds the dummy libgles1-mesa
User16: User15 thanks! i think it makes sense to do that, just for self-consistency, right?
User15: sure
User15: didn't think of 3rd party packages actually depending on it..
User15: silly intel
User16: yeah :)
User15: now to fix libxfont1..
User16: slashd: are you going to merge nagios-nrpe? You TIL
User16: slashd: i might just do it myself
User16: slashd: just uploaded (fyi) so you're off the hook :)
User16: User12 looks like src:nspr can be synced right? you did an artful update to bump to 4.13.1 but debian now has 4.15
User12: probably, it usually goes with nss, but they're pretty good about not breaking abi
User12: User16 ^
User16: User12 ack, i'm looking at nss too
User16: User12 i think, if i'm reading it right, nss can be synced too (need to check on the ubuntu2 upload to see if it's an upstream fix or not)
User12: nothing in the nss release notes strikes me at being particularly problematic
User16: User12 ack, i'll review our delta more closely tmrw, but i'll probably submit the syncs tmrw
User16: User12 thanks!
ubuntu-devel
Ubuntu IRC