[02:05] <imgbot> [03:05] <imgbot> [03:30] <imgbot> [03:30] <imgbot> [03:40] <tedg> trainguards, Can I get a silo for line 51?
[03:41] <robru> tedg: ha! you just caught me on the way out for dinner. silo 11.
[03:43] <tedg> robru, Awesome, thanks! :-)
[03:45] <robru> tedg: you're welcome
[04:20] <imgbot> [04:20] <imgbot> [04:23] <ToyKeeper> Hmm, that answers that question.
[05:41] <Mirv> morning
[05:47] <Mirv> hmm, wtf happened to my qtdeclarative line on spreadsheet, and how does it seem bzoltan's line 40 has kind of assimilated it
[05:49] <Mirv> bzoltan_: could you look at line 40 and and least make it like you'd like it to be? the MP is about phablet-tools, yet the bug is about qtdeclarative and it has qtdeclarative as manually uploaded package
[05:49] <bzoltan_> Mirv:  geez... not again a CI sheet conflict
[05:51] <Mirv> bzoltan_: I haven't seen that, but is it something like not everything is shown to everyone, then they add a line, and they somehow get mixed up?
[05:51] <Mirv> I can see sil2100 "reconfigured" my silo adding phablet-tools to it.. https://ci-train.ubuntu.com/job/prepare-silo/4142/console
[05:51] <Mirv> but the bug link isn't from my line even
[05:51] <Mirv> yes it's qtdeclarative but not the bug my landing in silo 012 was supposed to be about :S
[05:52] <bzoltan_> Mirv:  I do not know.  Sometimes it goes away.
[05:56] <Mirv> robru: it can't go away if a silo has already been reconfigured to have two landings mixed :)
[05:56] <robru> Mirv: true
[05:56] <Mirv> go Google!
[05:57] <robru> Mirv: yeah i dunno how this is getting worse, replacing the spreadsheet is top priority
[06:52] <oSoMoN> ogra_, hey, if/when you’re around, I need a packaging ack for https://ci-train.ubuntu.com/job/ubuntu-landing-025-2-publish/17/artifact/packaging_changes_webbrowser-app_0.23+15.04.20150217.1-0ubuntu1.diff
[06:54] <oSoMoN> trainguards: good morning! I need a binary copy of oxide-qt 1.5.3-0ubuntu1 from https://launchpad.net/~phablet-team/+archive/ubuntu/ppa/+packages to silo 3
[06:55] <robru> Mirv: can you grab that? I'm afk
[06:58] <Mirv> robru: sure
[06:58] <Mirv> oSoMoN: sure
[06:58]  * Mirv is very sure
[06:58] <robru> Mirv: thanks ;-)
[06:58] <Mirv> oSoMoN: I tried also on #ubuntu-devel but maybe we need ogra if no-one else volunteers
[07:01] <Mirv> oSoMoN: we got it from mitya57
[07:04] <oSoMoN> Mirv, thanks!
[07:04] <Mirv> now all I'd need is an archive admin to approve compiz-mate binary package addition, no luck yesterday or today so far
[07:17] <bzoltan_> Mirv:  was the rtm image 237 ditched or what?
[07:29] <robru> Mirv: Hmmmmmmm silo 3 diff is empty, that's suspect.
[07:31] <Mirv> bzoltan_: I'm not sure, you mean in terms of verification? I think signoffing and landing is still ongoing today.
[07:31] <Mirv> robru: maybe because it needs to diff around 2.5GB against another 2.5GB, something runs out?
[07:32] <Mirv> robru: luckily not disk space though :)
[07:33] <robru> Mirv: I should hope that debdiff tool doesn't explode just because the filesize
[07:33] <Mirv> robru: no, it's not that, I've debdiffed oxide locally just fine
[07:33] <robru> Mirv: I'm poking at it now...
[07:35] <robru> Mirv: oh I see... one sec
[07:38]  * ToyKeeper wonders when bfiller gets up...  probably not for several more hours
[07:39] <robru> ToyKeeper: gets up? hah! he probably just went to bed recently. it's not even midnight us west coast
[07:39] <ToyKeeper> Probably need to confirm if a silo can land even though the bugfix has an unfortunate side effect.
[07:39] <ToyKeeper> (in rtm-017, one of the bug fixes eliminates an accidental feature which allowed it to produce higher-quality photos)
[07:41] <robru> Mirv: oh btw, what I told you before about needing FORCE_REBUILD and WATCH_ONLY to regenerate diffs is no longer true. WATCH_ONLY now regenerates diffs by itself, that seemed more sensible to me.
[07:44] <Mirv> robru: right, that's great!
[07:44] <Mirv> ToyKeeper: the usual default is indeed that flash is used for focusing if when flash itself is turned off
[07:45] <ToyKeeper> Mirv: But it no longer uses the flash for focusing after applying this bugfix.
[07:46] <Mirv> ToyKeeper: yes, I just mean that indeed that's wrong, the default should be flash used for focusing even if there wouldn't be a setting for controlling it
[07:47] <Mirv> or well, I have seen also phones that do this same thing.
[07:47] <ToyKeeper> Ah, okay.  So it sounds like this is less a grey matter and more of a fail.
[07:47] <Mirv> yes it's a rather grey matter. some people prefer that they can actually make the phone not to use the flash (for example it's banned to use flash in museums)
[07:48] <ToyKeeper> Oh, it definitely is better to have the option rather than letting the phone be too smart for its own good.  :)
[07:49] <ToyKeeper> But I feel that way about pretty much any attempt at software being clever.
[07:56] <bzoltan_> Mirv:  I mean that the RTM #237 is not listed here -> http://people.canonical.com/~ogra/touch-image-stats/rtm/ But it was the latest proposed when I validated the UITK landing... and it brought a broken gallery what made my testing invalid. Not nice ...
[08:01] <robru> Mirv: hah: https://ci-train.ubuntu.com/job/ubuntu-landing-003-1-build/lastSuccessfulBuild/artifact/full_oxide-qt.diff/*view*/ 366MB diff, got it working at least.
[08:08] <Mirv> robru: now we just need to review it properly!
[08:08] <Mirv> but yes, working = good
[08:08] <robru> Mirv: good luck ;-)
[08:09] <Mirv> bzoltan_: that's probably just ogra's scripts not running or something, as it's missing 237+238
[08:09] <ogra_> well, there were most likely device tarball or custom tarball changes ... if there are no rootfs changes -> no changelog
[08:10] <Mirv> oh right, there were those
[08:10] <seb128> is anyone looking at u1 accounts being lost on rtm > 234 updates?
[08:10] <ogra_> seb128, it is most likely due to the server wanting to refresh the token ...
[08:11] <ogra_> your token gets invalid on the phone when that happens
[08:11] <ogra_> we need better user feedback for this
[08:11] <seb128> why is that happening only after an update?
[08:12] <seb128> ogra_, dbarth is saying something else on -touch
[08:12] <ogra_> dunno ... before the old account stayed around and people were wondering why app updates stopped workin
 seb128: apparently because the apparmor extension is missing, and the u1 lib now expects it to be there
[08:12] <ogra_> how could that lib land without this in place ?
[08:13] <ogra_> this needs to be a dependency then
[08:14] <seb128> https://bugs.launchpad.net/ubuntu/+source/signon/+bug/1392380/comments/17
[08:14] <seb128> so yeah
[08:14] <seb128> bug, not token from server issue
[08:15] <bzoltan_> ogra_: Mirv:  anyhow, there must be a gallery app change between 236-237 what introduced failing tests
[08:16] <ogra_> seb128, well, 239 has the fix then
[08:17] <seb128> my u1 account is not back though
[08:18] <seb128> dbarth, ^ do we need to add the account again anyway?
[08:20] <bzoltan_> ogra_: Mirv: can you guys confirm this gallery change?
[08:21] <ogra_> bzoltan_, i can confirm that no rootfs changes happened :)
[08:21] <ogra_> nothing else
[08:21] <Mirv> bzoltan_: ogra_: no, gallery is <IP_ADDRESS>6 from end of January
[08:22] <bzoltan_> ogra_:  so you say that the 236 and 237 are identical? Because I did capture a gallery test regressions.
[08:22] <ogra_> no, i say that the rootfs hasnt changed
[08:22] <ogra_> iirc 237 had some fixed for factory mode or so ...
[08:23] <ogra_> *fixes
[08:23] <ogra_> in the device tarball
[08:23] <ogra_> and 238 was a new custom tarball ... no idea what changed there
[08:24] <bzoltan_> Mirv: Ok, the gallery did not change. What about the gallery tests?
[08:24] <Mirv> bzoltan_: the RTM branch of gallery is untouched
[08:25] <Mirv> bzoltan_: but, maybe the phablet-click-test-setup checks out trunk instead?
[08:25] <bzoltan_> Mirv:  something caused the gallery test failures from 236 to 237
[08:25] <Mirv> bzoltan_: oSoMoN fixed gallery-app test failures in _trunk_ 19 hours ago https://code.launchpad.net/~phablet-team/gallery-app/trunk
[08:25] <Mirv> if phablet-click-test-setup checks out trunk AP:s instead of rtm AP:s, that would explain it
[08:26] <bzoltan_> Mirv:  Yeps... that was it. 19 hours ... that is exactly between my reference  and silo testing
[08:26] <Mirv> bzoltan_: so it's not tests failing, it's wrong tests
[08:27] <Mirv> bzoltan_: but nothing in rootfs really changed in 237 and 238
[08:27] <bzoltan_> Mirv:  Clear.
[08:41] <bzoltan_> brendand: jibel: Guys, I have marked the silo1 tested and pasted the test results to the usual cell in the sheet. The silo validation for UITK takes ages, like 12-14 hours a round. You do not need to run the test plan. All the tests are done. If you have questions please ping me _and_ kalikiana. I hope that this UITK fix can make it to the the w9 freeze.
[08:43] <Mirv> bzoltan_: we'll have a hangout in 45mins, after that we'll know more
[08:44] <bzoltan_> Mirv:  Cool :) please push the UITK :)
[08:45] <jibel> bzoltan_, that'll be short for this milestone. There are still huge updates in the queue, like calendar and camera
[08:45] <jibel> bzoltan_, but we'll do our best
[08:49] <bzoltan_> jibel: it is up to you guys. The cursors issue this UITK fixes seemed to be rather important
[08:49] <seb128> dbarth, so, should I add back my u1 account manually, or keep it in that state in case somebody wants to fix it and need a system to verify the fix on?
[08:56] <brendand> Mirv, any idea why QLibrary.load() would fail?
[08:58] <brendand> Mirv, the error looks like this - http://pastebin.ubuntu.com/10287481/
[09:00] <Mirv> brendand: at least out of context that doesn't tell me anything.. it'd sound like it doesn't find a library or something?
[09:01] <brendand> Mirv, yeah. i'm not really sure where it looks
[09:02] <brendand> Mirv, the location is on both QT_PLUGIN_PATH and LD_LIBRARY_PATH
[09:15] <dbarth> seb128: you can add it back, we have a way to reproduce in a bug report
[09:15] <seb128> dbarth, thanks
[09:15] <dbarth> seb128: mardy is looking into this right now
[09:15] <seb128> great
[09:52] <popey> sil2100: jibel if we add calendar to dashboard, won't that need calendar to already be in the image?
[09:52] <sil2100> seb128: hey! Do you know if there's any progress made on the failing ubuntu-system-settings AP tests?
[09:52] <davmor2> popey: it will be in the next image unless things go very wrong
[09:53] <jibel> popey, it should be on next image
[09:53] <popey> ok
[09:53] <sil2100> popey: as they mentioned, it should be in the next image so we should be safe to add it now
[09:53] <popey> ok
[09:53] <jibel> and if it is not and it fails, we'll know why :)
[09:53] <popey> hah
[09:53] <seb128> sil2100, no, we have no clue what's the issue, we can't reproduce on devices and the issue on the ci run seems in qtfeedback
[09:53] <sil2100> seb128: the changes that are causing almost all tests to fail also landed on ubuntu-rtm yesterday and we would need those fixed before we can get an image promoted
[09:53] <seb128> that's what I understood from what Ken said the other day
[09:53] <sil2100> oh
[09:54] <popey> cihelp Hello! Can we please get calendar app autopilot tests added to the dashboards? (it was removed a while ago, but we're adding it back to the image)
[10:08] <bzoltan_> sil2100: jibel: I saw that we have time until 2pm UTC. Who to bribe to pull the UITK up in prioroty? It has a fix what effect _ALL_ text input in _ALL_ apps.
[10:08] <sil2100> bzoltan_: no worries, QA will sign-off your silo after silo 11 and calendar
[10:09] <bzoltan_> sil2100:  Okey...now all I need is an IBAN number and a sum :D
[10:32] <jibel> sil2100, +1 for gallery app
[10:33] <sil2100> \o/
[10:33] <sil2100> Publishing
[10:35] <jibel> sil2100, you upload to the store as well?
[10:35] <sil2100> jibel: and what about the qtdeclarative5-ubuntu-ui-extras0.2 package in the end?
[10:35] <jibel> sil2100, it is wrong in vivid too. You have a click app that depends on an external lib that is not part of the framework but added manually to the seed
[10:36] <sil2100> jibel: hm, but I don't see it in ubuntu-rtm right now - will we need to land the camera-app silo first?
[10:36] <sil2100> rmadison says it's only in vivid currently
[10:37] <jibel> sil2100, it's in 17, bfiller said "No because gallery-app click package does not need ui-extras0.2 yet and we are not installing the gallery-app deb which has this dependency"
[10:38] <jibel> sil2100, I don't quite understand why the click package wouldn't need this lib
[10:39] <jibel> sil2100, the lib is not embedded in the click package, so if it is not installed on the system it'll use the wrong version
[10:39] <sil2100> Ah, hm
[10:39] <sil2100> Ok
[10:39] <jibel> sil2100, I don't know what in gallery app uses this lib and if it detects which version is available at runtime
[10:40] <jibel> sil2100, I think it's safer to wait for silo 17 to land too
[10:40] <sil2100> Not sure what to do in this case, as even though the .deb packages are basically just dummy ones, but this will mean I'll push a broken-dep package to the archive
[10:40] <sil2100> jibel: yeah
[10:40] <sil2100> Ok, let's just wait then :)
[10:40] <sil2100> Thanks!
[10:41] <jibel> sil2100, but IMO this lib should be a dependency of an ubuntu-sdk-lib-extras which would be a suggest of ubuntu-sdk-lib and -extras would be added to the seed. and if the version of the lib changes you bump the version of the framework
[10:43] <jibel> sil2100, probably cleaner than adding that lib manually to the seed. You cannot even track which click package depends on it, and that'll probably break stuff next time it's updated to a major version
[10:54] <psivaa_> popey: I've added your request to our 'To do' lane
[10:54] <psivaa_> Doing this should not take that long but it could be a little while for us to get there
[10:54] <psivaa_> s/there/to it
[10:54] <popey> thanks psivaa_
[10:54] <psivaa_> np
[11:28] <jibel> cihelp: on http://rtm-dashboard.ci.ubuntu.com/smokeng/utopic/touch_stable/krillin/239:20150218:20150216-fe747ac/332/ 3 tests are failing because system-settle failed (abook, dialer and calc) Where do I find info why it failed? There is not much info in top-before and top-after log files
[11:29] <sil2100> jibel: ogra_ had a nice script to parse it for useful information
[11:30] <jibel> ogra_, ^ do you mind sharing your script?
[11:30] <ogra_> paste.ubuntu.com/10289122/
[11:31] <ogra_> i havent used it in ages, not sure it still works
[11:31] <jibel> ogra_, I'll try, thanks!
[11:32] <vila> jibel: pas mieux
[11:34] <jibel> sil2100, ogra_ I don't see anything interesting in topafter but it's likely the scoperunner crash that generated the load
[11:35] <jibel> davmor2, did you notice any crash while testing the custom tarball?
[11:36] <davmor2> jibel: nope
[11:42] <sil2100> I go prepare lunch
[11:45] <rvr> popey: Calendar app: text: "W"+ root.startDay.weekNumber()
[11:45] <rvr> popey: "W" must be localized
[11:46] <rvr> popey: Also, pot file needs update, "All Day" is not available in Launchpad for translations.
[12:24] <Mirv> sil2100: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-005-1-build/112/console ...
[12:24] <Mirv> sil2100: I once ran build with watch_only quite quickly after uploading the final version, now it's like that..
[12:25] <sil2100> huh?
[12:25] <Mirv> sil2100: I guess just another way CI Train may "save" some wrong information and not clear that out
[12:25] <Mirv> sil2100: note how it checks two versions of the same package
[12:26] <sil2100> Mirv: yeah, probably try doing a normal non-watch_only build
[12:26] <sil2100> But I guess it's a bug indeed
[12:26] <sil2100> watch_only should not use any saved state for source packages
[12:26] <Mirv> sil2100: normal build same problem it seems https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-005-1-build/113/console
[12:27] <sil2100> huh
[12:27] <sil2100> Ok, now that's broken then
[12:27] <sil2100> Let me take a look in-between frying
[12:33] <sil2100> hm
[12:34] <sil2100> Mirv: from the CI Train side everything looks ok, I wonder what the new build job does
[12:35] <Mirv> sil2100: the old version is not even shown at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-005/+delete-packages anymore
[12:37] <popey> rvr: can you file a bug pls?
[12:38] <Mirv> sil2100: maybe it's still something that will sort itself by time, ie. the LP query will return different results at some point.
[12:38] <rvr> popey: Yes, we can
[12:39] <popey> thanks
[12:43] <rvr> popey: https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1423160
[12:43] <popey> thanks rvr
[12:57] <Mirv> sil2100: ok, it still failed I now did _both_ prepare-silo reconfig + tagged force_rebuild of both packages (even though they are manual uploads and not MP:s). either of them finally cleared the wrong info out.
[13:00] <sil2100> Mirv: geh, ok...
[13:18] <boiko> trainguards: question: the silo request on row 56 does not change existing code, just remove some toos that were not being used for quite some time on history-service, do I need to put QA signoff as Required still?
[13:28] <sil2100> boiko: I would say it shouldn't require sign-off, since the diff indeed looks sane
[13:28] <sil2100> boiko: but shouldn't you also remove history-service-tools from debian/control?
[13:28] <boiko> sil2100: well, that's the thing: on vivid we added new tools, I just don't want to backport them right now
[13:40] <sil2100> boiko: ok, yeah, but in ubuntu-rtm it would mean that we'll have an empty package basically, right?
[13:40] <sil2100> Not a super bad thing though
[13:41] <boiko> sil2100: yep, at least until we backport the new tools (they help testing, as they populate the history database, etc)
[13:54] <pete-woods> trainguards: hi, could I get vivid silo 011 reconfigured please? thanks!
[13:56] <Mirv> pete-woods: sure
[13:56] <sil2100> pete-woods: done
[13:56] <sil2100> Mirv: ^
[13:57] <Mirv> sil2100: hehe :)
[13:57] <Mirv> pete-woods: and thanks for the fix already in advance!
[13:57] <sil2100> boiko: ok, assigned the silo, but QA might want to re-discuss the requirement of sign-off
[13:58] <boiko> sil2100: that's fine, I was just trying to leverage their work :)
[14:00] <bfiller> jibel, sil2100: gallery-app click package does not depend on ui-extras0.2 yet so that is not needed technically
[14:00] <bfiller> it will need it in the future but doesn't right now
[14:00] <pete-woods> Mirv: well, importantly this won't be truly fixed until the apps are updated to stop doing their own translations for infographics (see MR for music-app https://code.launchpad.net/~unity-team/music-app/infographics-translations/+merge/248251)
[14:02] <bfiller> sil2100: kenvandine can ack the packaging changes in silo 18, he's aware of the situation
[14:02] <kenvandine> hey bfiller
[14:02] <sil2100> bfiller: ok... if a core-dev acks that then it's fine, but basically right now the deb will be uninstallable on ubuntu-rtm
[14:02] <sil2100> I know we don't use the .deb basically
[14:02] <kenvandine> sil2100, have you seen anything like this?  http://pastebin.ubuntu.com/10290989/
[14:03] <sil2100> But if something lands in the archive it should have archive-sufficient quality
[14:03] <bfiller> sil2100: yes that is true, but we don't use the deb at all. it's only there for convergence to install on desktop
[14:03] <sil2100> bfiller: I'll let kenvandine as the core-dev to decide ;)
[14:03] <bfiller> sil2100: so lets sync ui-extras then from vivid at the same time
[14:03] <sil2100> bfiller: yeah, it's in another silo which seems to have some problems currently
[14:04] <sil2100> Otherwise I would just sign-off and land both
[14:04] <bfiller> sil2100: we can move that into it's own silo so it can land independently
[14:04] <sil2100> bfiller: no worries, let's wait a bit on how things resolve and decide then if we need to hack around it
[14:04] <kenvandine> sil2100,  i'm fine acking that for rtm
[14:05] <kenvandine> we aren't running desktops from rtm anyway
[14:05] <bfiller> sil2100, kenvandine : ok thanks guys
[14:05] <sil2100> Ok then, let me publish it :)
[14:05] <kenvandine> thanks
[14:05] <kenvandine> sil2100, and look at that pastebin when you get a chance :)
[14:05] <sil2100> kenvandine: ok, looking now
[14:05] <jibel> bfiller, there is a fix for the camera, so it should land later today, and ui-extras0.2 too
[14:05] <kenvandine> that's what we're getting from smoke tests
[14:06] <kenvandine> sil2100, which i've reproduced on my krillin running vivid locally
[14:06] <sil2100> kenvandine: hm, now that's something I never saw before
[14:06] <kenvandine> also...
[14:06] <sil2100> kenvandine: it started happening after the u-s-s silo landed... was there anything risky in it?
[14:06] <kenvandine> this started happening between image 96 and 98
[14:06] <kenvandine> which had a massive mir landing
[14:06] <bfiller> jibel: ok cool, thanks
[14:07] <kenvandine> sil2100, there was also a mir landing
[14:07] <kenvandine> there was nothing risky in the silo
[14:07] <kenvandine> sil2100, in fact... the only change in that silo was adding some UI that is hidden
[14:07] <sil2100> kenvandine: but not in ubuntu-rtm - and we see the same failures in rtm with the latest image
[14:07] <kenvandine> wait... same thing in rtm?
[14:08] <sil2100> kenvandine: http://rtm-dashboard.ci.ubuntu.com/smokeng/utopic/touch_stable/krillin/239:20150218:20150216-fe747ac/332/ <- this is the latest result in rtm after landing of the u-s-s silo, no failures seen before this
[14:08] <sil2100> http://people.canonical.com/~lzemczak/landing-team/ubuntu-rtm/239.commitlog
[14:08] <sil2100> These are the changes
[14:08] <kenvandine> sil2100, so the same change landed in rtm, and the UI isn't hidden there
[14:09] <sil2100> This is why I started thinking that it's this landing that's responsible
[14:09] <kenvandine> sil2100, what image did it start happening in for rtm?
[14:09] <sil2100> WIth this one
[14:09] <sil2100> 239
[14:09] <kenvandine> that is the latest right?
[14:09] <sil2100> http://rtm-dashboard.ci.ubuntu.com/smokeng/utopic/touch_stable/ <- all others have normal failure counts
[14:09] <sil2100> Yes :)
[14:09] <kenvandine> well wtf@
[14:09] <sil2100> We would really like to have this resolved as it's blocking our promotion
[14:10] <kenvandine> sil2100, the change we landed in 239 also landed yesterday in vivid
[14:10] <sil2100> Since releasing OTA-1 with so many failures is really bad ;p
[14:10] <kenvandine> this has been happening for over a week in vivid
[14:10] <sil2100> hmm
[14:10] <sil2100> Interesting
[14:10] <bfiller> sil2100: I will push the gallery-app click to the store now, is that ok?
[14:11] <kenvandine> sil2100, and... the only change in the image that this was introduced in with vivid had landed in rtm a week before it landed in vivid
[14:12] <seb128> kenvandine, hey, getting anywhere with the u-s-s test issue?
[14:12] <kenvandine>  #15 0xaf0763ce in QFeedbackHapticsEffect::QFeedbackHapticsEffect(QObject*) () from /usr/lib/arm-linux-gnueabihf/libQt5Feedback.so.5
[14:12] <kenvandine> same damn thing
[14:13] <kenvandine> seb128, that's what sil2100 and i are talking about
[14:13] <kenvandine> seb128, it just started happening in rtm smoke testing
[14:13] <seb128> kenvandine, weird
[14:13] <kenvandine> in image 239
[14:13] <sil2100> brb
[14:13] <kenvandine> seb128, and there are strange logs
[14:14] <kenvandine> http://pastebin.ubuntu.com/10290989/
[14:14] <kenvandine> seb128, ^^ thoughts?
[14:14] <seb128> kenvandine, not really, does it have to do with screencasting?
[14:15] <seb128> how is the screencasting working?
[14:15] <kenvandine> oh i wonder if that is what's causing that log
[14:15] <kenvandine> i don't know
[14:15] <seb128> can we enable it locally to see if we hit the same issue?
[14:16] <kenvandine> i have reproduced it locally
[14:16] <kenvandine> on my krillin with vivid
[14:16] <kenvandine> oh
[14:16] <kenvandine> that can't be screencasting
[14:16] <kenvandine> i get that same log output locally
[14:16] <seb128> k
[14:16] <kenvandine> [1424235205.472568] <ERROR> mircommon: Caught exception at Mir/EGL driver boundary (in setSwapInterval): /build/buildd/mir-0.11.0+15.04.20150209.1/src/client/buffer_stream.cpp(283): Throw in function virtual void mir::client::BufferStream::request_and_wait_for_configure(MirSurfaceAttrib, int)
[14:16] <kenvandine> Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorISt11logic_errorEEEE
[14:17] <kenvandine> that part anyway
[14:17] <seb128> did mir change in rtm?!
[14:17] <kenvandine> seb128, and at the same time, there's a seg fault from uss that seems to be triggered by haptic feedback
[14:17] <kenvandine> seb128, i don't think so
[14:17] <kenvandine> not in image 239
[14:17] <seb128> weird
[14:18] <kenvandine> seb128, but... there was a mir landing in the first vivid image that had this problem
[14:18] <seb128> doesn't explain why rtm get the same issue without a mir landing
[14:18] <kenvandine>  qtdeclarative5-ubuntu-ui-toolkit-plugin changed in image 236
[14:20] <kenvandine> seb128, the good news is this crash really happens at the very beginning of the test
[14:20] <kenvandine> everytime
[14:20] <kenvandine> and we aren't seeing this crash manually testing
[14:21] <kenvandine> so it must be something to do with the autopilot tests
[14:21] <kenvandine> and i've ruled out infrastructure by testing locally
[14:22] <kenvandine> i wonder if we're the only ones seeing this because we don't use upstart-app-launch
[14:35] <kenvandine> seb128, https://errors.ubuntu.com/problem/b4ceece27f0ccfe9753e940695015237461b3908
[14:35] <seb128> kenvandine, not very useful, why isn't retracing working?
[14:36] <bfiller> popey: can your review/ack new gallery I just uploaded to store?
[14:36] <kenvandine> seb128, that's what i was going to ask you :)
[14:36] <seb128> bdmurray, ^ can you help there?
[14:37] <popey> bfiller: done
[14:38] <kenvandine> also... all 3 instances of it where run by autopilot
[14:39] <kenvandine> seb128, https://errors.ubuntu.com/problem/f1aceaefc06bcc522f22df201625eb2d111929fb
[14:39] <kenvandine> that one has a retrace
[14:40] <sil2100> Publishing o/
[14:40] <seb128> kenvandine, right, who is working on the feedback plugin?
[14:40] <kenvandine> that's from qt
[14:41] <sil2100> bfiller: anyway, can you please upload the new gallery-app to the store? :)
[14:41] <kenvandine> seb128, i'd think that would affect all kinds of stuff
[14:41] <kenvandine> we don't do anything directly there
[14:41] <kenvandine> just the uitk
[14:42] <kenvandine> seb128, i created bug 1423205
[14:43] <bfiller> sil2100: done, popey just approved it
[14:43] <sil2100> Excellent
[14:44] <bfiller> sil2100: can I get a silo for line 58 on vivid, it's the camera-app fix need to land it in vivid first then will sync to rtm
[14:44] <sil2100> Sure, on it
[14:44] <bfiller> jibel: ^^^ the camera-app is fixed, just doing the vivid landing first then will update the rm silo
[14:44] <bfiller> rtm silo
[14:46] <om26er> kenvandine, Hi!
[14:47] <om26er> kenvandine, I am trying out silo 14. If the device does not discover the bluetooth name of the headset, it shows its MAC address, is it supposed to keep showing that until I connect to the headset ?
[14:48] <kenvandine> as long as it doesn't detect a name
[14:48] <kenvandine> it should
[14:48] <jibel> bfiller, OK, rhuddie ^ can you reverify the camera after silo 3?
[14:48] <om26er> kenvandine, how long does it take to detect the name generally ?
[14:48] <kenvandine> om26er, it might never
[14:48] <jibel> rhuddie, when it's in the silo of course :)
[14:48] <kenvandine> that was part of the problem
[14:48] <kenvandine> it would display an empty name
[14:48] <kenvandine> s/part//
[14:49] <rhuddie> jibel, sure. i just finished silo 3.
[14:49] <om26er> kenvandine, I think we need to add a testcase to the testplan for this bug fix.
[14:49] <kenvandine> om26er, so you have a device that doesn't get a name?
[14:49] <bfiller> rhuddie: I'll ping you soon when it's in the rtm silo
[14:49] <om26er> kenvandine, it showed its MAC address
[14:49] <rhuddie> bfiller, thanks.
[14:49] <kenvandine> om26er, to properly test this specific case, the tester needs a device that wouldn't show a name
[14:50] <om26er> hmmm, don't have that.
[14:50] <kenvandine> om26er, i don't have a device that doesn't show a name
[14:51] <om26er> kenvandine, let me clear there are three cases ? 1. where name is shown. 2. only MAC address, 3. No nothing and in that case we want to show "..." ?
[14:51] <kenvandine> om26er, for case 3 we want to show the address
[14:52] <kenvandine> om26er, it should only show the address when there is no name detected
[14:52] <kenvandine> om26er, i don't have any devices that don't show a name
[14:52] <kenvandine> for example
[14:53] <kenvandine> om26er, so showing the address shouldn't be common, i'd hope
[14:53] <om26er> I tried it in my car it showed the MAC address, the name only appeared when I connected to it.
[14:53] <kenvandine> om26er, cool, i think that's what we want
[14:53] <kenvandine> om26er, but there are some devices that'll never get a name
[14:54] <kenvandine> so we'll keep showing the address
[14:54] <kenvandine> om26er, but to test that you need a device that doesn't get the name
[14:54] <kenvandine> not sure we want to require everyone that tests this to have such a device
[14:55] <om26er> heh, I'll just approve it after some more testing.
[14:56] <kenvandine> om26er, thx... not sure how to test it
[14:56] <kenvandine> we tested it for regressions
[14:56] <kenvandine> well, pmcgowan did, not sure if he had a device that didn't detect the name or not
[14:57] <kenvandine> i tested it in vivid, all my devices still show the name
[14:58] <pmcgowan> kenvandine, om26er  my device initially shows the address, then when connnected switches to the name
[14:59] <kenvandine> pmcgowan, and is that the same behavior as before?
[14:59] <pmcgowan> kenvandine, before the field was blank the the first page, now it shows the address
[15:00] <kenvandine> pmcgowan, perfect!
[15:00] <kenvandine> so you have a device that reproduced the bug :)
[15:00] <kenvandine> pmcgowan, i tried everything in my house that has bluetooth... they all show a name before connecting
[15:01] <pmcgowan> yeah my headset showed the issue, whereas my car showed the name
[15:01] <pmcgowan> probably a bt version thingy
[15:02] <pmcgowan> sil2100, jibel  any chance we will get all the queued silos landed?
[15:03] <sil2100> pmcgowan: yes, although we might still be blocked on the failing autopilot tests for ubuntu-system-settings anyway
[15:03] <sil2100> pmcgowan: since currently we have almost all u-s-s tests failing
[15:03] <om26er> kenvandine, looking at the diff, previously if device was not paired you appended "..." now you are doing that for the opposite. Intentional ?
[15:03] <jibel> pmcgowan, all the critical fixes will land (9, 14, calendar and camera are under verification)
[15:03] <sil2100> kenvandine is looking into that
[15:03] <sil2100> pmcgowan: btw. did you hear anything about us not to include calendar-app?
[15:04] <ogra_> hmm
[15:04]  * ogra_ wonders why rmadison gives him 503 errors
[15:04] <jibel> pmcgowan, we'll maybe have time to land silo 1, depending how it goes with silos under testing.
[15:05] <pmcgowan> jibel, silo 0 is also a customer report fix
[15:05] <pmcgowan> and silo 20 just looks like great fixes
[15:06] <pmcgowan> but gotta stop sometime
[15:06] <sil2100> pmcgowan: but 0 doesn't seem to look ready
[15:06] <jibel> pmcgowan, but it is not ready for QA. last comment from rsalveti is "Not yet to be validated, WIP (had tested as yes by accident)."
[15:06] <pmcgowan> ok
[15:06] <rsalveti> pmcgowan: jibel: yeah, we found one issue with silo 0, working on the fix
[15:06] <rsalveti> so not completely ready yet
[15:07] <kenvandine> om26er, indeed that does look opposite... cyphermox ^^
[15:07] <kenvandine> om26er, good eye...
[15:08] <pmcgowan> sil2100, I did not hear anything about calendar app
[15:08] <sil2100> pmcgowan: since I was wondering how to include it and cwayne mentioned something about Joe saying not to add it yet
[15:08] <kenvandine> cyphermox, before you only appended "..." if it wasn't paired, now you're only appending it if it is paired
[15:08] <sil2100> But I wonder what that means
[15:08] <pmcgowan> let me check
[15:09] <cyphermox> kenvandine: indeed, it's a logic error
[15:09] <kenvandine> cyphermox, can you fix that up quickly?
[15:09] <pmcgowan> sil2100, last email I have on this joe just says keep him posted
[15:09] <kenvandine> we really want to land that today
[15:10] <kenvandine> om26er, i'll rebuild that silo as soon as cyphermox fixes that
[15:10] <kenvandine> om26er, thanks for catching that!
[15:10] <om26er> kenvandine, ok sure ;-)
[15:10] <cyphermox> kenvandine: pushed
[15:10] <kenvandine> cyphermox, thx!
[15:11] <kenvandine> cyphermox, i'll fix it for trunk
[15:11] <cyphermox> k
[15:11] <jibel> pmcgowan, this is what we found with the calendar app so far: bug 1423185, bug 1423191, bug 1423209, bug 1362781, bug 1347836
[15:11] <cwayne> pmcgowan: sil2100: just got a hard -1 on adding calendar
[15:11] <pmcgowan> cwayne, ok
[15:11] <sil2100> cwayne: oh? What's up?
[15:11] <pmcgowan> all those bugs
[15:11] <pmcgowan> jibel, thanks
[15:12] <sil2100> jibel: thanks!
[15:12] <jibel> pmcgowan, I don't see it in the list but event syncs doesn't work reliably
[15:13] <pmcgowan> jibel, how so?
[15:13] <jibel> pmcgowan, someone in the team reported that this morning during our standup, I'll find the bug
[15:16] <alan_g> plars: Are there problems on mir-mediumtests-runner-mako? Just had this twice "Rebooting the phone will take approximately 30 seconds to settle/Build timed out (after 60 minutes). Marking the build as failed."
[15:16] <plars> alan_g: not that I've heard of, but I'm just coming on. Can you point me at the job?
[15:17] <alan_g> https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/4328/console (and 4389)
[15:17] <cwayne> sil2100: it's a bit too risky to add a new app this late in the game
[15:19] <kenvandine> cyphermox, mind an ack? https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/address-not-name-rtm-logic-error/+merge/250152
[15:19] <plars> alan_g: on a standup right now, give me just a bit and I'll take a look
[15:19] <jibel> bfiller, any ETA for the update of the camera app in RTM?
[15:19] <alan_g> plars: ok
[15:19] <cyphermox> kenvandine: thar.
[15:20] <kenvandine> cyphermox, thx
[15:20] <bfiller> jibel: within 30 minutes, landing in vivid currently
[15:20] <jibel> bfiller, thanks
[15:29] <bfiller> sil2100: mind publishing ubuntu silo 27 for camera-app
[15:30] <om26er> bzoltan_, Hi!
[15:31] <om26er> bzoltan_, I can't select text in unity' searchbar with silo1, the actionbox takes over the selector.
[15:32] <om26er> more like the handlers hide
[15:35] <jhodapp> sil2100, can I get a silo for line 59 please
[15:37] <om26er> kalikiana, ^
[15:40] <bdmurray> seb128, kenvandine: this is the log file portition for the retrace attempt - https://pastebin.canonical.com/125821/
[15:41] <bdmurray> pitti might have more information about why retraces fail like that
[15:41] <kenvandine> bdmurray, thx for looking
[15:41] <kenvandine> i found a retrace
[15:42] <seb128> bdmurray, thanks
[15:42] <bdmurray> kenvandine: where?
[15:42] <kenvandine> https://errors.ubuntu.com/problem/f1aceaefc06bcc522f22df201625eb2d111929fb
[15:44] <jhodapp> cyphermox, can I get a silo for line 59 please?
[15:45] <cyphermox> jhodapp: sure
[15:45] <jhodapp> cyphermox, looks like i jsut got on, thanks anyway
[15:45] <jhodapp> sil2100, thanks man!
[15:45] <bfiller> rhuddie: here is the update click to test for silo 17: https://jenkins.qa.ubuntu.com/job/generic-click-builder-vivid-armhf/342/artifact/output/com.ubuntu.camera_<IP_ADDRESS>4_armhf.click
[15:46] <rhuddie> bfiller, jibel, thanks. I'll start testing
[15:47] <kenvandine> sil2100,  you can rest easier... the always awesome jgdx has a fix for the smoke test failures!
[15:47] <kenvandine> and it's just in the autopilot tests
[15:47] <kenvandine> nothing wrong with settings itself
[15:47] <sil2100> Oh OOH!
[15:47] <sil2100> :D
[15:48] <kenvandine> it actually removes one test :/
[15:48] <kenvandine> but that one test blows the entire suite
[15:49] <kenvandine> we're not 100% sure why yet... but something to do with the session bus
[15:52] <kenvandine> sil2100, we're still investigating a proper fix that wouldn't make us remove that test
[15:54] <sil2100> jibel: ^
[15:54] <sil2100> kenvandine: what test needs removing to fix the suite?
[15:58] <kenvandine> sil2100, it's the ConnectivityMixin class that's causing the problems, which is needed by test_sim_unlock
[15:59] <sil2100> jibel: ^ do you it is acceptable to temporarily get rid of the test for this release to make all the other tests working again?
[15:59] <kenvandine> sil2100, jibel: and the problem with the test has nothing to do with a feature regression...
[15:59] <kenvandine> it's just problems with the session bus
[16:00] <kenvandine> and the uitk using the session bus to get the vibrate settings
[16:01] <kenvandine> om26er, silo 14 is built again
[16:01] <om26er> kenvandine, thanks, will test that in a bit
[16:01] <kenvandine> -            if (device->isPaired())
[16:01] <kenvandine> 9	+            if (!device->isPaired())
[16:01] <kenvandine> om26er, the only diff
[16:01] <om26er> yeah I saw that.
[16:01] <kenvandine> om26er, thx
[16:02] <sil2100> kenvandine: anyway, I'd like QA to decide if we can go with that, but seeing how things are going I suppose that's our only choice
[16:02] <om26er> kenvandine, approved.
[16:02] <sil2100> If we intend to get an image ready by the end of the UTC day
[16:02] <kenvandine> om26er, thx!
[16:06] <sil2100> kenvandine: ouch...
[16:06] <sil2100> kenvandine: I can't publish silo 14 as there was a release in the meantime
[16:06] <sil2100> So we might need to rebuild the silo ;/
[16:06] <kenvandine> what?
[16:06] <kenvandine> i just rebuilt it
[16:06] <kenvandine> oh
[16:06] <kenvandine> i already published it :)
[16:07] <kenvandine> sil2100, sorry... that broke you :)
[16:07] <sil2100> Ahah
[16:07] <sil2100> :D
[16:07] <kenvandine> sil2100, i'll prepare a silo dropping that test, in case we want to land that
[16:07] <sil2100> Right, I always forget you publish your own silos :D
[16:07] <sil2100> kenvandine: yes, please
[16:08] <kgunn> sil2100: hey so your mail, are you saying gate is closed even for things that were ready tues morning...but in the qa test queue ?
[16:09] <bzoltan_> om26er:  if you have any problems or question related to the silo1,  please feel free to reach out :)
[16:09] <sil2100> kgunn: the gates are closed for new things, but not all silos prepared before the deadline will make it as it depends on QA capabilities ;)
[16:09] <om26er> bzoltan_, I did already :)
[16:10] <sil2100> kgunn: the highest priority are silos with critical or factory fixes
[16:10] <kgunn> got it...
[16:10] <sil2100> Others will land if QA is able to sign-off
[16:10] <om26er> bzoltan_, I can't select text in unity' searchbar with silo1, the actionbox takes over the selector.
[16:10] <kgunn> ours is under qa test atm
[16:10] <om26er> bzoltan_, http://i.imgur.com/xse3evb.png
[16:12] <kenvandine> sil2100, we're going to hold off proposing that for trunk though, so vivid smoke testing will remain broken for now
[16:12] <kenvandine> while we find a proper fix
[16:12] <kenvandine> that way we don't forget to fix it :)
[16:13] <jibel> kenvandine, sil2100 do we know exactly why the tests are failing?
[16:13] <sil2100> kenvandine: hm, ok, makes sense, even though I think it would be best if this gets fixed ASAP anyway since for quality we need to make sure that all automated tests work as they should
[16:15] <kenvandine> sil2100, yes... jgdx is working on it now
[16:16] <kenvandine> jibel, a test in our security panel starts a session bus
[16:16] <kenvandine> jibel, but now the uitk is needing the session bus so it gets started already
[16:16] <kenvandine> we're getting conflicting session buses
[16:16] <kenvandine> we think
[16:16] <kenvandine> jibel, so removing that ConnectivityMixin class we have, prevents that from happening
[16:17] <kenvandine> jibel, once it blew up, everything after it fails
[16:17] <kenvandine> we only need to remove it from the one test
[16:17] <jibel> kenvandine, OK, can you update the silo?
[16:18] <kenvandine> jibel, i just created a silo with it
[16:18] <kenvandine> jibel, we're leaving it broken in vivid for now
[16:18] <kenvandine> to keep the pressure on a proper fix
[16:18] <sil2100> kenvandine: remember that we first need the other u-s-s silo to merge-and-clean fully
[16:18] <kenvandine> sil2100, yes...
[16:18] <kenvandine> not building until then
[16:18] <bzoltan_> kalikiana: ping
[16:18] <sil2100> Excellent :)
[16:18] <jibel> kenvandine, fine, it's better than being completely blind
[16:19] <kalikiana> bzoltan_: pong
[16:19] <kenvandine> jibel, right... we know it isn't a real failure, just causing all hell to blow up in the test :)
[16:19] <bzoltan_> kalikiana:  om26er sees this http://i.imgur.com/xse3evb.png
[16:19] <bzoltan_> om26er:  what version of the UITK you have on the device?
[16:20] <kalikiana> bzoltan_: hmmm the handlers are missing?
[16:20] <bzoltan_> kalikiana: yes indeed
[16:20] <om26er> bzoltan_, 1.1.1298+15.04.20150218~rtm-0ubuntu1
[16:20] <kalikiana> om26er: how did you select that text?
[16:21] <om26er> kalikiana, double tap
[16:25] <bfiller> kenvandine: any way to speed up landing camera-app which is in proposed? http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=camera
[16:25] <bfiller> itching to rebuild sync silo
[16:25] <kalikiana> om26er: hmm can repro. and it's indeed the change to blame… no idea, though, what is happening, never seen that
[16:25] <kenvandine> bfiller, no... i don't think so
[16:26] <bfiller> kenvandine: like watching paint dry
[16:26] <kenvandine> bfiller, it usually takes about an hour
[16:26] <kenvandine> yeah
[16:26] <bfiller> ok
[16:27] <kenvandine> bfiller, why aren't you on the slopes?
[16:27] <kenvandine> if it's because of  camera-app, i can help :)
[16:27] <bfiller> kenvandine: going this afternoon :)
[16:28] <plars> alan_g: Looks like it was a weird fluke with that device, but the device seems fine now. I've restarted the job and I'll continue to monitor it
[16:30] <alan_g> plars: thanks
[16:30] <kalikiana> om26er: bzoltan_ I'll need to look into what unity is doing there. it has a custom clear button for some reason, but that doesn't easily explain this funny bug.
[16:31] <om26er> kalikiana, ok, i'll fail the silo for now.
[16:33] <bzoltan_> om26er: please hold a bit
[16:35] <om26er> bzoltan_, ok, moved back.
[16:37] <sil2100> davmor2: you signing-off location-service?
[16:38] <sil2100> Are we ok with getting a risky component like that in this milestone?
[16:39] <jibel> sil2100, it's in OTA1 priorities
[16:40] <sil2100> It was? hmmm
[16:40] <davmor2> sil2100: factory bug for battery drain aiui jibel okayed it
[16:40] <sil2100> I missed it completely
[16:41] <sil2100> jibel, davmor2: hm, the spreadsheet doesn't mention it as being reported by BQ/CKT
[16:42] <davmor2> sil2100: the battery drain general bug is though and this is a sub branch from that
[16:55] <rhuddie> bfiller, is there an update required on the rtm silo for the camera-app fix?
[16:56] <bfiller> rhuddie: we should rebuild the camera-app deb once it lands in vivid but stuck in proposed
[16:56] <jhodapp> sil2100, not sure what happened here, any insight? https://ci-train.ubuntu.com/job/ubuntu-landing-028-1-build/23/console
[16:56] <bfiller> rhuddie: since we don't use the deb it can probably land as is if all the testing done
[16:57] <bfiller> rhuddie: I just need to upload the click you tested to the store
[16:57] <jhodapp> sil2100, actually nevermind, the more detailed logs for each ARCH point out what's wrong
[16:57] <sil2100> jhodapp: it seems the packages failed to build in the PPA
[16:58] <jhodapp> sil2100, yeah, missing build dep
[16:58] <rhuddie> bfiller, this click is giving me a problem loading the app
[16:58] <bzoltan_> om26er:  I pull off that MR from the landing silo and leave the oneliner to fix the other bug. If you culd wait a half an hour
[16:58] <bfiller> rhuddie: what do you mean?
[16:59] <om26er> bzoltan_, sure thing.
[16:59] <rhuddie> bfiller, well, I've installed it with the silo updates, when I launch it, I see the camera screen load briefly and then it disappears
[16:59] <bzoltan_> om26er:  at least we ship two bugfixes with this round
[17:00] <bfiller> rhuddie: I'm not seeing that, anything in the log? ~/.cache/upstart/application-click-com.ubuntu.camera_<version>.log
[17:01] <plars> alan_g: it's looking like my retry is going to suffer the same fate - I think it could be your change that's killing it
[17:02] <plars> alan_g: it's on a different device this time, and it was fine after the base install, but not after installing your update and rebooting
[17:02] <alan_g> plars: I'll take another look at it
[17:04] <kenvandine> bfiller, i feel your pain, i'm watching paint dry too.. with settings
[17:04]  * kenvandine twiddles thumbs
[17:04] <bfiller> rhuddie: I'm seeing the issue, checking the problem
[17:05] <rhuddie> bfiller, this is my log: http://pastebin.ubuntu.com/10293406/
[17:09] <bfiller> Kaleo: the click for camera-app that was built by jenkins has some issues, getting undefined symbols
[17:09] <bfiller> Kaleo: see rhuddie log above, I'm seeing the same
[17:10] <bfiller> Kaleo: did something change in qtubuntu-camera in vivid that is needed now in RTM?
[17:31] <Kaleo> bfiller, dunno of that, but we changed only one line since you last built a click
[17:31] <Kaleo> bfiller, checking
[17:31] <bfiller> Kaleo: I just rebuilt the click, trying that now.
[17:32] <Kaleo> bfiller, it looks nothing like any change that may have been made to any of the code
[17:32] <Kaleo> bfiller, it looks more like something in the build env that has changed
[17:33] <Kaleo> bfiller, it's the first time we actually use the camera click pkg produced by jenkins no?
[17:33] <Kaleo> bfiller, usually we build it ourselves IIRC
[17:33] <Kaleo> bfiller, both for testing and publishing
[17:34] <bfiller> Kaleo: we always use jenkins, ok here is a new one I built with jenkins seems to work http://people.canonical.com/~bfiller/com.ubuntu.camera_<IP_ADDRESS>5_armhf.click
[17:34] <bfiller> Kaleo: please verify to make sure that has nerochiaro's change and that it's working correctly
[17:35] <Kaleo> bfiller, you built that one *with* jenkins?
[17:35] <bfiller> Kaleo: yes, but did it manually and didn't take the one jenkins built via CI
[17:35] <Kaleo> bfiller, I see
[17:35] <bfiller> not sure what the difference is but the app launches now :)
[17:35] <bfiller> rhuddie: http://people.canonical.com/~bfiller/com.ubuntu.camera_<IP_ADDRESS>5_armhf.click
[17:35] <Kaleo> bfiller, ok
[17:38] <mzanetti> trainguards: can someone please rebuild qtsystems in silo0 for me?
[17:39] <robru> mzanetti: do you not have permission?
[17:39] <mzanetti> robru: afaik I can't no, because it's not added via the spreadsheet but uploaded manually
[17:39] <robru> mzanetti: oh, hrm.
[17:39] <mzanetti> I might be wrong...
[17:39] <robru> mzanetti: so what, you need a no-change rebuild? you don't have a change to apply to it?
[17:39] <mzanetti> I pushed to the branch
[17:40] <mzanetti> oh, I see
[17:40] <mzanetti> one sec :)
[17:40] <mzanetti> robru: lp:~mzanetti/ubuntu/vivid/qtsystems-opensource-src/inputinfo
[17:41] <robru> mzanetti: oh ok, yeah I can upload that, one sec.
[17:41] <mzanetti> thanks
[17:41] <bzoltan_> om26er:  the silo1 is ready .. I ripped off the cursor "fix"
[17:42] <om26er> bzoltan_, thanks for that, I'll repick it after a few minutes. In a meeting right now.
[17:42] <nerochiaro> bfiller: Kaleo: i tested the image you linked and it seems to have my change and be working ok
[17:42] <bzoltan_> om26er:  OK, thanks for your patinece
[17:43] <Kaleo> nerochiaro, by image you mean click?
[17:43] <nerochiaro> Kaleo: sorry yes
[17:43] <Kaleo> bfiller, nerochiaro: I have tested the manually built click 515 and it works too
[17:44] <kenvandine> sil2100, is there an excuses page for rtm?
[17:44] <kenvandine> sil2100, it's taking unusually long for settings to make it to release
[17:44] <sil2100> kenvandine: yeah, one moment
[17:44] <sil2100> ugh
[17:44] <sil2100> Wait, wtf, it's gone
[17:45] <robru> mzanetti: what do you want in the changelog? eg what did you change?
[17:45] <sil2100> aaaha
[17:45] <sil2100> nvm
[17:45] <sil2100> kenvandine: http://people.canonical.com/~ubuntu-archive/proposed-migration/ubuntu-rtm/14.09_update_excuses.html
[17:45] <sil2100> hmm
[17:45] <kenvandine> sil2100, hmmm settings isn't on that
[17:45] <sil2100> it's outdated
[17:45] <kenvandine> oh... indeed
[17:45] <kenvandine> is something not running?
[17:46] <sil2100> cjwatson: are there any known problems with 14.09 migration right now?
[17:46] <sil2100> slangasek: ^ ?
[17:47] <robru> mzanetti: nm, got your commit message
[17:48] <slangasek> sil2100: I've just committed a merge of some changes from cjwatson to proposed-migration, could be related
[17:48] <cjwatson> sil2100: Heh, somebody merged my branches but one of them was deployed slightly differently live, so conflict
[17:48] <cjwatson> I'll fix
[17:48] <slangasek> oops
[17:48] <kenvandine> :)
[17:48] <slangasek> "deployed slightly differently live"?
[17:48] <kenvandine> cjwatson, thanks!
[17:48] <cjwatson> I deployed an earlier version of the output-prefix stuff because it was urgent for 14.09-factory
[17:48] <kenvandine> sil2100, i've been anxiously watching it so i could build that silo for you :)
[17:49] <robru> mzanetti: ok, new upload building, should be good to go
[17:49]  * cjwatson replaces with the committed version
[17:49] <cjwatson> sil2100: should work next time, thanks
[17:50] <cjwatson> slangasek: thanks for the merges
[17:50] <sil2100> kenvandine: ;)
[17:50] <slangasek> cjwatson: sure thing
[17:50] <sil2100> Thanks for fixing!
[17:50] <cjwatson> I guess I'd better run them by hand to catch up
[17:50] <sil2100> kenvandine: we'll spin a new image as soon as the current u-s-s migration finishes
[17:50] <kenvandine> cjwatson, that would be appreciated
[17:50] <sil2100> kenvandine: we can include the autopilot fixes later
[17:51] <kenvandine> sil2100, sure
[17:51] <sil2100> (as those don't require testing by QA anyway)
[17:51] <kenvandine> sil2100, ah... can you change that on the spreadsheet then?
[17:51] <kenvandine> i put required
[17:52] <sil2100> Sure
[17:52] <kenvandine> sil2100, thx
[17:52] <cjwatson> eek, this is crashing hard
[17:52]  * cjwatson disables archive-reports while he debugs
[17:52] <rhuddie> bfiller, Kaleo, thanks. confirm this version is now working and I get video thumbnail. One bug I've noticed is that the new photo-roll Edit option is enabled for videos, as well as photos
[17:54] <bfiller> rhuddie: that is indeed a bug
[17:54] <Kaleo> bfiller, shall we disable editing? :)
[17:54] <bfiller> Kaleo: if we don't seed qtdeclarative5-ubuntu-ui-extras0.2 then it will be disabled
[17:54] <Kaleo> bfiller, right
[17:55] <Kaleo> bfiller, is it seeded in vivid?
[17:55] <Kaleo> bfiller, it's not seeded anywhere atm right?
[17:55] <bfiller> Kaleo: it's seeded in vivid but not in rtm
[17:55] <Kaleo> bfiller, so we need to fix the bug regardless
[17:56] <bfiller> Kaleo: lets just fix it, should be simple
[17:56] <Kaleo> bfiller, ugo said it's prob easy
[17:56] <bfiller> we do the same already in gallery-app
[17:56] <Kaleo> bfiller, good, was gonna asxk
[17:56] <cjwatson> sil2100,kenvandine: should be happier now
[17:56] <Kaleo> -x
[17:57] <Kaleo> rhuddie, fixing now, should be a one liner :)
[17:57] <sil2100> cjwatson: yaay, thanks ;)
[17:57] <cjwatson> sil2100: note it's now http://people.canonical.com/~ubuntu-archive/proposed-migration/ubuntu-rtm/14.09/update_excuses.html, sorry for the rearrangements - I'll put symlinks or redirects or something in place in a bit
[17:57] <cjwatson> another reason I want to do a couple of runs by hand
[17:58] <rhuddie> Kaleo, thanks. I'm going to be eod soon, so somebody else will pick this one up again
[17:58] <Kaleo> rhuddie, understood, thanks
[17:58] <Kaleo> rhuddie, do you know who?
[18:01] <rhuddie> Kaleo, not yet. I'll update the card on the trello board with status. depends on how soon the next regression run starts.
[18:01] <Kaleo> rhuddie, any idea when that might be?
[18:01] <Kaleo> rhuddie, I mean, are we talking minutes hours or days?
[18:02] <rhuddie> Kaleo, well i believe new build should be within 2 hours
[18:02] <Kaleo> rhuddie, ah ok
[18:06] <kenvandine> cjwatson, thanks
[18:07] <kenvandine> sil2100, settings is in release now and i started building silo 11 for the test fix
[18:18] <om26er> bzoltan_, how can i verify fix for #1395118 ?
[18:19] <bzoltan_> om26er:  there is a demo code in the bug report
[18:20] <om26er> bzoltan_, if i put that into a .qml how can i launch it ?
[18:21] <bzoltan_> om26er:  just open the Ubuntu SDK, create a simple UI template app and copy that code over the main.qml
[18:30] <sil2100> kenvandine: thanks!
[18:30] <sil2100> Ok, let me check proposed and build a new image
[18:31] <sil2100> kenvandine: ok, so we have gallery-app stuck in -proposed because of missing qtdeclarative5-ubuntu-ui-extras0.2 , but we have a click for that anyway
[18:31] <kenvandine> yeah
[18:50] <imgbot> [18:58] <pmcgowan> boiko, sil2100 are we able to land silo 15? that has the last critical fixes
[18:58] <sil2100> pmcgowan: too late
[18:58] <pmcgowan> sil2100, those are factory fixes, so maybe not
[18:59] <sil2100> pmcgowan: the silo is still not set as ready...
[18:59] <boiko> pmcgowan: testing it
[18:59] <sil2100> pmcgowan: and we really need time to test the image, I already kicked off the first promotion candidate
[19:00] <pmcgowan> sil2100, I understand but won't matter if factory doesnt accept it
[19:00] <pmcgowan> john-mcaleely, ^^ what do you think
[19:00] <pmcgowan> sil2100, we can start testing then consider poking that one silo in
[19:00] <sil2100> hm, we can get a new one re-spinned later I guess
[19:01] <pmcgowan> sil2100, remember that was our plan to consider factory fixes late
[19:01] <john-mcaleely> sil2100, delay gets my vote, or land it late after QA with some retesting of that area?
[19:01] <sil2100> I'm a bit worried with the tight timeline, but yeah
[19:02] <john-mcaleely> pmcgowan, ^ as we discussed, I htink
[19:02] <pmcgowan> agreed, lets get it ready for QA then decide
[19:02] <john-mcaleely> yeah, nothing to be done until that state is reached
[19:02] <sil2100> Since it's ofono-related then I would actually wait with testing until it lands
[19:03] <sil2100> As it would require retesting a lot of things anyway
[19:04] <john-mcaleely> makes sense
[19:04] <pmcgowan> right agreed
[19:04] <sil2100> boiko: how does it look so far? You think it will be ready for sign-off in the nearest hours?
[19:05] <sil2100> I'll have to disconnect in a few, but I'll get back in around 2 hours in case an image needs to be built
[19:07] <sil2100> ToyKeeper: hey! Just so you know, if you see silo 15 as ready for sign-off please take care of it with priority ;)
[19:07] <sil2100> robru: ^ and if you could publish it with priority as well
[19:07] <robru> sil2100: sure thing
[19:07] <sil2100> Thanks :)
[19:07] <ToyKeeper> sil2100: Does that mean 240 isn't the promotion candidate, but 241 is?
[19:08] <boiko> sil2100: yep, it is looking good so far, should be ready for signoff pretty soon
[19:08] <sil2100> ToyKeeper: yeah, basically 241 will be the image we'd like to release
[19:09] <sil2100> kenvandine: ^ looks like your u-s-s autopilot fixes will still land in the promotion candidate ;)
[19:13] <rsalveti> triggering a new vivid for the new pulseaudio
[19:13] <kenvandine> Ran 121 tests in 1441.927s
[19:13] <kenvandine> OK
[19:13] <kenvandine> sil2100, ^^
[19:14] <sil2100> \o/
[19:15] <sil2100> Ok, need to drop off now, see you in a few hours
[19:15] <kenvandine> sil2100, should i publish that?
[19:15] <sil2100> kenvandine: hm, not sure if the rootfs for 240 already finished
[19:15] <imgbot> [19:15] <sil2100> kenvandine: maybe wait a few and then publish ;)
[19:15] <kenvandine> sil2100, a "few"
[19:15] <robru> kenvandine: rtm 11 doesn't need qa?
[19:15] <kenvandine> how long is that?
[19:16] <kenvandine> robru, no... autopilot only
[19:16] <kenvandine> fixes the smoke tests
[19:16] <robru> kenvandine: cool
[19:16] <sil2100> robru: no, it's just an autopilot change, but kenvandine will publish it if anything
[19:16] <robru> sil2100: k
[19:16] <sil2100> kenvandine: maybe in like 30 mins or so?
[19:16] <kenvandine> sure
[19:16] <sil2100> Thanks guys ;)
[19:17] <kenvandine> sil2100, how can i tell if it's safe?
[19:17] <kenvandine> sil2100, have a good one!
[19:17] <sil2100> kenvandine: hmm... there's a way of checking if the rootfs built but I never remember the links for that ;p
[19:17] <sil2100> See you in a bit o/
[19:22] <ToyKeeper> D'oh, too late.
[19:24] <ToyKeeper> robru, boiko: I can't test silo rtm-015.  The plan is to use 240 as the candidate and take rtm-015 a little slower.
[19:25] <ToyKeeper> It kinda requires specific test lab hardware and 4G, neither of which is available on this continent.
[19:25] <robru> ToyKeeper: hmmm
[19:26] <robru> ToyKeeper: ok well do what you can. if you can only test 240 then so be it. when the europeans wake up they can test 241 then.
[19:58] <boiko> ToyKeeper: so, bug 1421177 is marked as duplicate of another bug by john-mcaleely
[19:59] <boiko> john-mcaleely: can you confirm it is really just a duplicate?
[20:00] <john-mcaleely> boiko, looking
[20:02] <john-mcaleely> boiko, I went on the basis of the commenst in #18 & 19 on that bug
[20:02] <john-mcaleely> it seems that several bugs have poor repros (we lack the equipment), and an engineering call that they may have related fixes
[20:03] <boiko> john-mcaleely: the bug description is very confusing, but re-reading it I think it is correct, unless the reporter says it is not
[20:03] <john-mcaleely> boiko, so my biggest concern would be regressions, rather than confirming those branches fix things
[20:04] <john-mcaleely> boiko, we will not hear from the reporter - they were onsite for one day, and will not go back
[20:04] <boiko> john-mcaleely: so, the branch really fixes 1416292
[20:05] <john-mcaleely> boiko, again, we've never well reproduced that, so it's a judgement call, I think
[20:05] <boiko> john-mcaleely: the chances of regressions are very low
[20:05] <imgbot> [20:05] <imgbot> [20:05] <john-mcaleely> boiko, then I prefer to say we tried to fix it, and did make an improvement
[20:05] <boiko> john-mcaleely: and as I said before, 1416292 is really fixed
[20:05] <john-mcaleely> and therefore land '15
[20:05] <john-mcaleely> excellent
[20:06] <boiko> john-mcaleely: also, with the stuff that already landed on silo 11,  call accepting/hanging up handling was improved a lot
[20:06] <john-mcaleely> boiko, sounds good
[20:07] <boiko> ToyKeeper: so, I think testing the other bugs is enough in this case
[20:08] <john-mcaleely> I think that is the best we can do
[20:08] <boiko> ToyKeeper: also, 1422401 was partially fixed with a fix in ofono that was landed on silo 11, so if you try to reproduce the problem without silo 15, you might not succeed, the telephony-service side of the fix just cover extra failure possibilities
[20:09]  * john-mcaleely eod
[20:18] <robru> ToyKeeper: well there's that ^
[20:31] <ToyKeeper> Hmm, silo rtm-11 didn't actually land in image 240 though, no?
[20:31] <ToyKeeper> It was approved after 240 started building.
[20:31] <kenvandine> ToyKeeper, no it didn't
[20:32] <kenvandine> ToyKeeper, sil2100 wanted it to go in 241
[20:32] <ToyKeeper> Okay.  I'll try to avoid telephony tests on 240, since they'll be obsoleted by 241 anyway.
[20:33] <kenvandine> telephony?  rtm 11 was settings autopilot fixes
[20:33] <ToyKeeper> Okay, looks like there were two different silo 11s then.  :)
[20:33] <kenvandine> ah :)
[20:33] <kenvandine> rtm 11 with settings fixes the smoke test failures
[20:33] <kenvandine> autopilot test changes only
[20:33] <ToyKeeper> Regardless, image 241 should have some new telephony fixes.
[20:34] <kenvandine> ToyKeeper, so then the previous silo 11 should be in 240
[20:44] <boiko> ToyKeeper: flashing 240 here, I can tell if the fixes are there in a minute
[20:44] <ToyKeeper> boiko: I just had two silo 11s mixed up; wasn't aware there were two.
[20:45] <boiko> ToyKeeper: ah ok :)
[20:48] <plars> popey: so did I hear correctly that calendar is back?
[20:50] <imgbot> [20:50] <imgbot> [21:32] <kgunn> trainguard i can give up vivid silo 13
[21:32] <kgunn> trainguards i can give up vivid silo 13
[21:32] <robru> kgunn: sure
[22:33] <robru> cihelp s-jenkins is having some trouble: https://jenkins.qa.ubuntu.com/job/cu2d-choo-choo-autolanding/146/console seems intermittent, I've had some success with retries, but not always
[22:34] <fginther> robru, looking
[22:34] <robru> fginther: thanks
[22:36] <sil2100> o/
[22:36] <sil2100> Hey, did silo 15 land?
[22:37] <robru> sil2100: no, apparently ToyKeeper isn't equipped to qa it.
[22:37] <sil2100> Oh shit
[22:37] <robru> fginther: http://s-jenkins.ubuntu-ci:8080/job/cu2d-choo-choo-ci/ this is the one where the retry worked. the -autolanding one seems just dead
[22:38] <ToyKeeper> sil2100: Even so, I was asked not to, so people in .eu can do it in the morning.
[22:38] <robru> fginther: same traceback as far as i can tell
[22:38] <fginther> robru, there's an issue with a subset of the builder nodes, trying to track it down
[22:38] <sil2100> ToyKeeper: oh, who asked that?
[22:38] <robru> ToyKeeper: whoa whoa, I didn't ask you not to, I just suggested that .eu people could if you couldn't.
[22:38] <ToyKeeper> sil2100: One of the bugs in 15 can only be tested in the test lab, too.
[22:38] <ToyKeeper> Oh, jibel asked me not to.
[22:38] <sil2100> If that's the overall decision then ok, but now I'm really worried about time
[22:38] <robru> ToyKeeper: oh ok cool ;-)
[22:39] <sil2100> ToyKeeper: ok, then I trust that jibel knows best what resources QA has
[22:39] <sil2100> ToyKeeper: I suppose you could do sanity testing on #240 at least for krillin
[22:40] <ToyKeeper> Already doing that, and then on to regression testing for it...  just not the telephony parts.
[22:40] <sil2100> This way at least we'll know if images aren't completely broken
[22:40] <sil2100> Excellent
[22:41] <sil2100> Ok then, so it means I won't be needed
[22:41] <sil2100> See you tomorrow everyone o/
[23:03] <robru> fginther: ah, it merged now, thanks
[23:06] <fginther> robru, I found a corrupted project that appears to be the culprit. I'm now looking for the same problem on other nodes.
[23:06] <robru> fginther: good work!
[23:06] <fginther> robru, but things should be working for those jobs now


[00:19] -queuebot:#ubuntu-release- New source: plasma-wallpaper-dynamic (groovy-proposed/primary) [3.3.3-0ubuntu1]
[00:21] -queuebot:#ubuntu-release- New source: jack-mixer (groovy-proposed/primary) [13-0ubuntu1]
[00:35] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-189.219] (core, kernel)
[00:37] <vorlon> LocutusOfBorg: yeah, x264 just picked up another entangled transition from just-synced libcdio, so dumping contextfree now
[01:16] -queuebot:#ubuntu-release- New binary: ntopng [amd64] (groovy-proposed/universe) [3.8.1+dfsg1-1build1] (no packageset)
[01:22] -queuebot:#ubuntu-release- New binary: ntopng [armhf] (groovy-proposed/universe) [3.8.1+dfsg1-1build1] (no packageset)
[05:46] -queuebot:#ubuntu-release- New: accepted ntopng [amd64] (groovy-proposed) [3.8.1+dfsg1-1build1]
[05:46] -queuebot:#ubuntu-release- New: accepted ntopng [armhf] (groovy-proposed) [3.8.1+dfsg1-1build1]
[06:48] <Mirv> has the topic ever been discussed whether it could or should be prevented that urls like https://releases.ubuntu.com/20.04/ubuntu-20.04-desktop-amd64.iso stop working on the day of .1 release etc?
[06:48] <Mirv> or if that's preferable instead
[06:49] <Mirv> I could see it's preferable from letting people always use the official pages, but the official pages aren't localized so LoCos tend to maintain their own pages
[07:06] <Mirv> I'm also still missing Lubuntu 14.04 from old-releases, while it has been removed from releases
[07:28] <LocutusOfBorg> vorlon, you know, haskell-cborg-json might need another hammer? haskell-cborg-json unsatisfiable Build-Depends(-Arch) on armhf: libghc-cborg-dev (>= 0.2)
[07:37] <LocutusOfBorg> ghc: 8.8.4-1	proposed (universe)	8 hours ago
[07:37] <LocutusOfBorg> world: why do you hate me so much?
[07:38] <vorlon> LocutusOfBorg: sorry, that was an NBS binary in -proposed; I managed to remove -dev but not -prof
[07:38] -queuebot:#ubuntu-release- New: accepted hg-git [amd64] (groovy-proposed) [0.9.0-1]
[07:38] -queuebot:#ubuntu-release- New: accepted pytest-twisted [amd64] (groovy-proposed) [1.12-1]
[07:40] <LocutusOfBorg> vorlon, I would rollback ghc when it finishes building, so we can let this haskell migrate and start rebuilds?
[07:40] <vorlon> Mirv: I don't recall this having been discussed
[07:40] <LocutusOfBorg> thanks for doing it :)
[07:40] <LocutusOfBorg> (the json removal)
[07:40] <LocutusOfBorg> btw x264 rebuilds missed mythtv, I issued it now
[07:41] <vorlon> LocutusOfBorg: so this is rolling back to 8.8.3-3?
[07:41] <LocutusOfBorg> not sure if you left it behind because it was in multiverse, or something else :D
[07:41] <LocutusOfBorg> vorlon, rolling it back, will let the current mini transition end
[07:41] <vorlon> yeah, I didn't have multiverse enabled in my sources when I ran that script, sorry
[07:41] <LocutusOfBorg> but better wait for it to finish building? :)
[07:41] <vorlon> ok; in that case, catch me in my morning if no one else takes care of it
[07:42] <LocutusOfBorg> oh nice to know, I always wonder if people do not issue rebuilds because they know about some ftbfs or such
[07:42] <LocutusOfBorg> well, riscv64/armhf takes days to finish
[07:42] <LocutusOfBorg> I'm wondering if we should just kick it out
[07:42] <LocutusOfBorg> in days, the current ghc transition will end, I'm at level 18...
[07:42] <LocutusOfBorg> we can upload 8.8.4-1build1
[07:43] <LocutusOfBorg> so, if you want to kick it out, please go ahead :D
[07:46] <vorlon> done
[07:47] <vorlon> (rolling back ghc)
[07:49] <vorlon> rolling back dovecot :P
[08:00] <seb128> hey vorlon , I see you went for rolling back libreoffice, I guess it means no icu migration before next week now?
[08:00] <seb128> with hoping that the revert doesn't get the armhf issue...
[08:02] <seb128> (which I'm not convinced about since 6.4.5 autopkgtests are green on the focal SRU which is the same source so it could be a toolchain or rdepends issue)
[08:02] <Laney> I would have waited to hear back from us :/
[08:02] <Laney> I was quite deliberate in my use of skiptest vs badtest
[08:11] <LocutusOfBorg> tjaalton, what is happening?
[08:11] <LocutusOfBorg> dpkg: error processing archive /tmp/apt-dpkg-install-IzpqYj/460-libraspberrypi0_0~20200520+git2fe4ca3-0ubuntu1_armhf.deb (--unpack):
[08:11] <LocutusOfBorg>  trying to overwrite '/usr/lib/arm-linux-gnueabihf/libEGL.so', which is also in package libegl-dev:armhf 1.3.2-1
[08:12] <LocutusOfBorg> (mythtv fails to build on armhf) ^^
[08:14] <tjaalton> where?
[08:17] <LocutusOfBorg> mythtv on armhf
[08:17] <tjaalton> what's libraspberrypi0?
[08:17] <LocutusOfBorg> who knows?
[08:17] <tjaalton> complain to it's maintainer
[08:17] <LocutusOfBorg>  libraspberrypi0 | 0~20200520+git2fe4ca3-0ubuntu1 | groovy/universe | arm64, armhf
[08:17] <LocutusOfBorg> ok its mesa related, this is why I'm pinging you
[08:18] <tjaalton> libegl-dev is built by libglvnd
[08:18] <tjaalton> and it's the right place to have these
[08:19] <LocutusOfBorg> maybe on raspberrypi they need to break/replaces them?
[08:19] <tjaalton> pull-lp-source says it's not in ubuntu
[08:20] <LocutusOfBorg> tjaalton, not build on amd64
[08:20] <LocutusOfBorg> found it https://launchpad.net/ubuntu/+source/raspberrypi-userland/0~20200520+git2fe4ca3-0ubuntu1
[08:20] <LocutusOfBorg> waveform, ^^
[08:20] <LocutusOfBorg> I blame you :p
[08:27] <LocutusOfBorg> for now I'm removing libraspberrypi dependency on armhf
[08:29] <tjaalton> libEGL.so (and libGLESv2.so) are only built on armhf for some reason, arm64 doesn't build those
[08:30] <LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/libglvnd/+bug/1891613
[08:30] <LocutusOfBorg> tjaalton, ^^ if you want to provide some input, I opened a bug
[08:30] <tjaalton> wrong target
[08:30] <tjaalton> ah it had both
[08:30] <tjaalton> I already commented the packaging bug
[08:31] <tjaalton> breaks/replaces would be wrong, as the system would still have libEGL.so.1 from libglvnd
[08:32] <tjaalton> libegl1 deb
[08:39] <LocutusOfBorg> thanks
[08:55] <seb128> Laney, thanks for the by team change review!
[08:57] <Laney> np
[08:57] <Laney> thanks for the change :>
[09:05] <seb128> Laney, I was thinking also adding the 'implicit depends' info to the report, does that make sense to you? it would give some context for e.g libcdio ... but things changed there right? those used to be candidate but fail in update_excuses no?
[09:11] <Laney> seb128: might get too noisy?
[09:11] <Laney> you could maybe say 'breaks some other packages, see excuses'
[09:13] <seb128> right, those lists are a bit long, that might be an option
[09:16] <seb128> or maybe it's ok if that's a list space separate of source names without an entry for each arch?
[09:16] <seb128> Laney, thanks for the input, I will try and see how the reports looks like
[09:43] <juliank> Laney: Just saw the email with the instances without autopkgtests, are you looking into that by any chance?
[09:44] <juliank> Oh I see ones from 9 hours ago, I guess spam filter ate the ones in between
[09:44] <Laney> juliank: nop
[09:45] <juliank> so many errors, aargh!
[09:45] <juliank> are tests still running?
[09:45] <juliank> the queues seem empty
[09:46] <Laney> yes it looks ok
[09:46] <Laney> are you talking about bos02?
[09:47] <juliank> bos02 seemed to cause some errors last night
[09:47] <juliank> also is there a bug in urllib3?
[09:48] <juliank> ah but yes, these errors are all bos02
[09:48] <Laney> maybe there was some overnight blip
[09:48] <juliank> Traceback (most recent call last):
[09:48] <juliank>   File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 377, in _make_request
[09:48] <juliank>     httplib_response = conn.getresponse(buffering=True)
[09:48] <juliank> TypeError: getresponse() got an unexpected keyword argument 'buffering'
[09:48] <Laney> if those instances are stuck deleting, ask the ~IS vanguard to reset-state active && delete them
[09:48] <juliank> hmm
[09:48] <juliank> this is weird
[09:48] <juliank> :D
[09:49] <Laney> dunno what that is
[09:49] <juliank> the errror is WARNING:root:instance adt-groovy-s390x-emboss-20200813-193914 (29072e49-ea49-40b1-97ff-5bf1283648ad) has no associated autopkgtest (auth_url: http://keystone.infra.bos02.scalingstack:5000/v2.0/)
[09:49] <juliank> for a bunch of them
[09:49] <Laney> they look stuck, it happens when the cloud has a sad sometimes
[09:49] <Laney> go ask IS to intervene per ^
[09:49] <Laney> perhaps that situation also tickles a bug in the openstack client tools :(
[09:51] <juliank> I'll retry and look if it still happens
[09:57] <Laney> cheers!
[09:57] -queuebot:#ubuntu-release- Unapproved: accepted bind9-libs [source] (focal-proposed) [1:9.11.16+dfsg-3~ubuntu1]
[10:13] -queuebot:#ubuntu-release- Unapproved: accepted build-essential [source] (focal-proposed) [12.8ubuntu1.1]
[10:17] -queuebot:#ubuntu-release- New binary: build-essential [amd64] (focal-proposed/main) [12.8ubuntu1.1] (core, i386-whitelist)
[10:36] <waveform> LocutusOfBorg, thanks for the ping - taking a look
[10:50] <doko> Laney: LO succeeded to build in the groovy test rebuild
[11:29] <tjaalton> waveform: you probably shouldn't need to build libEGL etc on armhf, check why it does build them and disable by force if necessary
[11:30] <waveform> tjaalton, indeed - it's building a brcm-specific EGL for use on the pi0-3 apparently (and the arm64 builds done't include them as the pi4 only supports the mesa drivers and the pi foundation only (officially) support arm64 on the pi4)
[11:31] <tjaalton> ugh
[11:34] <waveform> just digging into the cleanest way of dealing with this - apparently there are some vaguely important use-cases where the brcm-specific EGL is needed, but the library seems to build both libEGL and libbrcmEGL (+all the rest) so I'll try and excise the former and leave the latter
[11:35] <tjaalton> so the worst-case scenario is that you rename the conflicting libs (to have a .1), then add diversions
[11:36] <tjaalton> libGLESv2.so -> libGLESv2.so.2
[11:43] -queuebot:#ubuntu-release- New binary: budgie-wallpapers [amd64] (groovy-proposed/universe) [20.10] (personal-fossfreedom, ubuntu-budgie)
[11:44] <tjaalton> waveform: I think the entrypoint for the brcm-stuff is in libEGL/GLESv2, so looks like you can't avoid shipping them
[11:47] <waveform> actually I'm not so sure about that ... just noticed libEGL.so has exactly the same size as libbrcmEGL.so which makes me ... suspicious - just digging into the CMake stuff
[11:48] <waveform> ah yes, just compiled from the same source with different names below the comment "# recommended names to use to avoid conflicts with mesa libs" :)
[11:49] <waveform> so, should be okay to exclude the "mesa-named" duplicates and just leave the brcm ones
[11:50] <tjaalton> okay..
[12:00] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (focal-proposed) [2.664.5]
[12:02] -queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (bionic-proposed) [2.525.46]
[12:05] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.47]
[12:07] <LocutusOfBorg> waveform, can you please ping back once you have a fix?
[12:07] <waveform> LocutusOfBorg, will do
[12:07] <LocutusOfBorg> so I can fix mythtv :D
[12:10] -queuebot:#ubuntu-release- Unapproved: rejected intel-microcode [source] (bionic-proposed) [3.20191115.1ubuntu<IP_ADDRESS>]
[12:43] <waveform> LocutusOfBorg, added a patch to LP: #1891613
[13:02] -queuebot:#ubuntu-release- Builds: 42 entries have been added, updated or disabled
[14:11] <LocutusOfBorg> waveform, sponsoring
[14:41] -queuebot:#ubuntu-release- New binary: linux-signed-azure-4.15 [amd64] (bionic-proposed/main) [4.15.0-1093.103] (no packageset)
[15:32] <vorlon> Laney, seb128: if you're comfortable with a skiptest on libreoffice, we can still cancel out this rebuild and revive the 6.4.5 binaries
[15:35] <vorlon> but what the heck do we do with node-redis anyway, it regresses on arm64 with a no-change rebuild of nodejs
[15:36] <Laney> vorlon: I only skiptested some other things which were waiting on this libreoffice
[15:36] <Laney> let's see how your 6.4.4 pans out, if that fails too then I have some gcc-9 builds in progress which might (or might not) fare better
[15:39] <rbalint> vorlon, i've just started reproducing node-redis, will see how it goes
[15:40] <seb128> Laney, but then we still need to wait for days of libreoffice rdepends validating their autopkgtests, including retries because we know those are flaky
[15:40] <vorlon> rbalint: bdmurray said he got it to work in canonistack, so maybe this is something that needs to be added to the big_test list instead of long_test?
[15:40] <vorlon> we have individual test timeouts, which were maybe borderline before and succeed in a heftier environment
[15:40] <rbalint> vorlon, sounds possible
[15:41] <seb128> Laney, vorlon , I've a feeling it's going to take at least another week until we clear our a libreoffice rebuilds :/
[15:41] <rbalint> vorlon, also if it passes locally we can just hint it
[15:42] <bdmurray> speaking of node-redis I'll remove it from long_tests since that was an error
[15:42] <vorlon> seb128: I hope not, 6.4.5 builds only need 19h and if the tests are /working/, that should only be another 100h
[15:42] <vorlon> sorry, 10h ;)
[15:42] <vorlon> bdmurray: do you want to go ahead and add it to big_tests at the same time and we'll see what happens?
[15:42] <bdmurray> vorlon: okay
[15:42] <seb128> vorlon, let's see on monday I guess
[15:42] <Laney> seb128: libreoffice only has a few rdepends, it's not that bad
[15:43] -queuebot:#ubuntu-release- New binary: haskell-gi-pango [ppc64el] (groovy-proposed/universe) [1.0.22-1build1] (no packageset)
[15:43] <seb128> Laney, right, I guess it's ok when we don't have a backlog of 3 days on armhf as we had recently
[15:44] -queuebot:#ubuntu-release- New binary: haskell-gi-pango [amd64] (groovy-proposed/universe) [1.0.22-1build1] (no packageset)
[15:44] -queuebot:#ubuntu-release- New binary: haskell-gi-pango [s390x] (groovy-proposed/universe) [1.0.22-1build1] (no packageset)
[15:45] <rbalint> vorlon, bdmurray ok, then i don't try reproducing node-redis again, moving on to other packages
[15:46] <bdmurray> vorlon: updated
[15:50] <vorlon> tjaalton: fwiw livecd-rootfs 2.525.47 was accepted despite being built with wrong -v option, and there's no SRU tracking for the bug linked from the 2.525.46 changelog...
[15:55] <bdmurray> LocutusOfBorg: juliank suggested another packaging change for bug 1886748 - moving libomp-9-dev from a Recommends to a Suggests of clang-9. Would that work for you?
[15:56] <juliank> I feel like I want to have distribution upgrade hints for apt at some point
[15:56] <juliank> but also this would be hard to hint :D
[15:57] <juliank> I should just get a new state of the art solver done
[15:59] -queuebot:#ubuntu-release- New binary: haskell-gi-pango [arm64] (groovy-proposed/universe) [1.0.22-1build1] (no packageset)
[16:02] <vorlon> bdmurray: workers restarted with updated config, if you want to retry node-redis
[16:05]  * Laney fixes .manifest on ancientminister to unbreak sync-mirrors
[16:06] <bdmurray> vorlon: I've pushed the button
[16:07] <Laney> no idea why it was only budgie triggering that
[16:10] <vorlon> xnox: did you not have a git branch somewhere for the proposed grub preinst work?
[16:15] <rbalint> ubuntu-archive, could you please demote rust-tokio-core do groovy-proposed due to LP: #1891679 to unblock other rust packages?
[16:16] <rbalint> ubuntu-archive or i should ask for a batch later
[16:17] <vorlon> rbalint: demote> no, but I'll remove it
[16:18] <vorlon> the package build-depends on an obsolete version, so it's not going to come back without a sourceful fix - so I don't want this cluttering -proposed, I want it removed to leave the Debian maintainers to deal with it
[16:18] <LocutusOfBorg> bdmurray, I don't understand to be honest, if it works, I'll be happy
[16:19] <rbalint> vorlon, ack, thanks, would you be open to demotions for packages that can migrate in theory later>
[16:19] <rbalint> ?
[16:19] <vorlon> rbalint: yes
[16:23] <vorlon> xnox: n/m, found the preinst mp, thanks
[16:23] <vorlon> rbalint: yes
[16:25] <doko> vorlon: tjaalton wants a SRU template for your pycurl SRU
[16:28] <vorlon> fair
[16:29] -queuebot:#ubuntu-release- Unapproved: gnome-shell (bionic-proposed/main) [3.28.4-0ubuntu18.04.3 => 3.28.4-0ubuntu18.04.4] (desktop-extra, mozilla, ubuntu-desktop)
[16:34] <vorlon> tjaalton, doko: added
[16:37] <xnox> vorlon:  i'm discussing it with debian maintainer, and we don't want preinst work.
[16:37] <vorlon> xnox: why?
[16:37] <xnox> vorlon:  adding checks in postinst, to check that devices exist before calling grub-install. Such that MBR and /boot never get out of sync.
[16:37] <xnox> vorlon:  having newer modules in /usr/lib is ok (and like non-matching the ones in /boot)
[16:38] <xnox> vorlon:  also it's my action to follow up on all that.
[16:38] <vorlon> xnox: having them in /usr/lib allows for the possibility that other packages might call grub-install behind our back despite grub-pc not being configured
[16:38] <xnox> vorlon:  apart from cloud-init, which we are the ones pushing to call grub-install, what else calls grub-install?
[16:39] <xnox> other packages only call update-grub that regenerates grub.cfg, but doesn't update mbr/efi.
[16:39] <xnox> (and i consider shim-signed/grub-* packages to be cooperating ones)
[16:39] <vorlon> xnox: and if it's a non-interactive upgrade, your only choice in the postinst is to exit 1, which leaves the package unconfigured; don't we think that's worse that having it fail to unpack?
[16:40] <vorlon> xnox: yeah and shim only calls grub-install for the efi target, so not affected.  Ok, if we expect nothing to call grub-install behind our backs, then that part is reasonable
[16:40] <xnox> vorlon:  failing preinst will leave the system in a worse state, aborting upgrade transaction much earlier.
[16:40] <xnox> (with a lot more packages unpacked, and not configured)
[16:41] <vorlon> xnox: I don't see why this is a worse state
[16:42] <vorlon> unpacked but not configured> do-release-upgrade attempts to clean this up
[16:47] <xnox> vorlon:  if that's your agrument, surely it should be 'config' and not 'preinst'. and it will none-the-less duplicate a lot of the question logic, no?
[16:47] <vorlon> xnox: config does not block the upgrade.
[16:47] <vorlon> apt ignores non-zero exit values when invoking the config scripts in the pre- stage
[16:48] <LocutusOfBorg> waveform, and it migrated, thanks for fixing so quickly
[16:48] <xnox> amazing
[16:48] <waveform> LocutusOfBorg, no prob - slightly embarrassed I didn't notice the armhf issue before! (spending too much time on arm64 :)
[16:49] <xnox> vorlon:  i feel that postinst fixes are a must. preinst fixes are nice to have. in the context of non-interactive upgrades => postinst is what we must fix.
[16:49] <vorlon> xnox: fair.  but we also need to fix the behavior of grub-install itself
[16:49] <xnox> vorlon:  in terms of do-release-upgrade, i feel there might not even be any need to fix anything, becuase it is interactive, and the failed-devices debconf flow is asked.
[16:50] <vorlon> the user might have set a non-interactive frontend for do-release-upgrade, I think?
[16:50] <xnox> vorlon:  and yes, behaviour of grub-install itself is suboptimal, and needs to be fixed upstream. That is a separate task from maintainer scripts stuff.
[16:50] <vorlon> xnox: it is a separate task, but also blocking for turning on 20.04 upgrades
[16:50] <xnox> vorlon:  and what colin is fixing is not just "exit 1" but "do not attempt to call grub-install when devices are non-existant" meaning exit 1 is before attempting to bork the machines.
[16:51] <xnox> with that fix alone, it would be enough to turn on upgrades. As postinst will fail non-interactively without borking things up.
[16:51] <xnox> and interactively there is failed-devices flow to correctly upgrade.
[16:51] <xnox> without a huge code dump of preinst changes or grub-install itself fixes.
[16:52] <xnox> also i'm failing at not working =)
[16:52] <xnox> vorlon:  i'd like to see postinst changes that colin is thinking off, to prevent calling grub-install on any devices, if any of the install-devices are missing.
[16:52] <vorlon> that's fine
[16:52] <vorlon> we still have the weird case in amazon where grub-install is called for a device that exists, then strangely fails
[16:53] <xnox> (that seems to achieve what we desired with preinst, whilst keeping all that in postinst)
[16:53] <vorlon> amazon?  azure
[16:53] <xnox> azure yes.
[16:53] <xnox> on a single serial which i am still debugging.
[16:53] <vorlon> regardless, despite being uncommon, I'd like us to have grub-install itself robustified before turning on upgrades
[16:53] <xnox> i have copies of what is in azure, and what we have locally, that do not match.
[16:53] <vorlon> anyway, this can all wait until Monday
[16:53] <xnox> it seems like an image got somehow missbuilt/missuploaded
[16:54] <xnox> "I'd like us to have grub-install itself robustified before turning on upgrades" => ack.
[16:54] <vorlon> I just was making sure we had a proper tracking bug for this (whose description / scope can be amended as appropriate) to make it clear to the release team what is blocking turning on upgrades
[16:55] <xnox> ack
[16:58] <xnox> vorlon:  it really does feel like "grub-install" was only ever meant as install, and was never meant to be "upgrade"
[17:08] <rbalint> vorlon, rust-gtk was removed with 'broken with new dh-cargo', but it is now in testing in Debian again
[17:09] <rbalint> vorlon, could you please resurrect it to groovy-proposed or is should get more confirmation that it would work?
[17:09] <rbalint> vorlon, or i should upload it with build1 myself
[17:15] <Laney> rbalint: you should be able to do the copy back to proposed yourself, just fyi - assuming no rebuid is needed vs the previous binaries
[17:15] <Laney> bye o/
[17:23] <rbalint> Laney, wow, thanks!
[17:23] -queuebot:#ubuntu-release- New sync: rust-gtk (groovy-proposed/primary) [0.7.0-1]
[17:42] -queuebot:#ubuntu-release- Packageset: Added redkite to ubuntustudio in groovy
[17:54] <vorlon> rbalint: yeah, copy-package -b -e $version --force-same-destination -s groovy-proposed $srcpkg
[18:49] <rbalint> vorlon, it worked, but i still need it to be accepted from NEW :-)
[18:49] <rbalint> vorlon, so please accept it
[18:56] -queuebot:#ubuntu-release- New binary: haskell-gi-pango [armhf] (groovy-proposed/universe) [1.0.22-1build1] (no packageset)
[18:58] -queuebot:#ubuntu-release- New binary: haskell-gi-pango [riscv64] (groovy-proposed/universe) [1.0.22-1build1] (no packageset)
[19:05] <sergiodj> friendly ping to archive-admin re. the telegraf package that's sitting on the NEW queue.  thanks
[19:46] -queuebot:#ubuntu-release- Unapproved: ceph (focal-proposed/main) [15.2.3-0ubuntu<IP_ADDRESS> => 15.2.3-0ubuntu<IP_ADDRESS>] (desktop-core, ubuntu-server)
[20:58] <LocutusOfBorg> please process haskell-gi-pango ^^
[21:26] <rbalint> ubuntu-archive please remove predictprotein https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963927
[21:27] <rbalint> ubuntu-archive please demote rust-crossbeam to groovy-proposed , it is removed from testing, too, and blocks rust-crossbeam-utils
[23:47] <bdmurray> vorlon: node-redis still failed