[00:08] <robru> wat
[06:24] <mardy> jgdx: hi! Not yet, but I've a branch for that
[08:59] <dbarth__> hey trainguards, seems that i can't fully publish siloe 056
[08:59] <dbarth__> https://ci-train.ubuntu.com/job/ubuntu-landing-056-2-publish/9/console
[08:59] <dbarth__> can you help?
[09:01] <pstolowski> sil2100, hey, any news on silo 24?
[09:05] <sil2100> pstolowski: checked that the new package reached the destination, force merging now
[09:07] <pstolowski> sil2100, great, thanks!
[09:44] <sil2100> Oh, queuebot is gone
[09:45]  * sil2100 needs to jump out for a min, brb
[09:58] <mardy> dbarth__: mmm... silo 56 is dirty again :-/
[10:00] <rvr> mardy: Hey. Did you see this? https://bugs.launchpad.net/bugs/1511055
[10:01] <mardy> rvr: no, I didn't... looks interesting :-)
[10:15] <dbarth__> mardy: oh is it?
[10:16] <dbarth__> i m still trying to get a trainguard to help me publish
[10:17] <dbarth__> let me check why
[10:47] <rvr> sil2100: Can you enable the s-i?
[10:49] <bzoltan_> sil2100:  how to deal with the gles packages now that we are targeting 16.04?
[10:49] <bzoltan_> sil2100:  the citrain is bitching that cp: cannot stat '/var/lib/jenkins/silos/ubuntu/landing-051/ubuntu-ui-toolkit_1.3.1705+16.04.20151029.1.orig.tar.gz': No such file or directory
[11:13] <cjwatson> sil2100: so, you know the way we keep a big git repository of Packages/Sources history in order that you folks can fork a factory PPA from an old version of the archive if you need to?  how far back do we need to keep that?
[11:14] <cjwatson> sil2100: I ask because even with git's amazing compression an 82GB repository is killing snakefruit and I'd like to truncate it
[11:15] <cjwatson> (it's not really about space, to be clear, it's that git gc kills the box daily)
[11:24] <sil2100> rvr: on it in a minute
[11:25] <sil2100> bzoltan_: that's hm, odd, let me check your silo in a moment
[11:27] <sil2100> cjwatson: hmmmm, I need to think about that, I think we might not need it anymore - you mean archive history, right? Since now that we basically use the overlay PPA and the overlay PPA has infinite history, we can get the exact package versions used from the image manifests + binary copies
[11:29] <cjwatson> sil2100: Both have infinite history, but working out the state of build-dependencies isn't something that manifests give you
[11:29] <cjwatson> sil2100: (We keep index history of the overlay PPA this way too)
[11:29] <cjwatson> sil2100: My question is just what the oldest point you might wish to fork from is
[11:30] <cjwatson> sil2100: right now we have back to somewhere around July/August 2014
[11:33] <bzoltan_> sil2100:  I ripped off the gles package .. but now it does the 15.04 versioned package only
[11:33] <sil2100> hm, I think that's indeed a bit too much into the past
[11:38] <sil2100> cjwatson: I think if the history would be spanned to around the 15.04 release, I suppose that would be sufficient
[11:38] <cjwatson> sil2100: righto, I'll see about filtering it, thanks
[11:38] <cjwatson> I'd like to keep ALL THE THINGS but it's not feasible at the moment :-/
[11:45] <sil2100> rvr: what device do you want to test on?
[11:45] <sil2100> rvr: krillin?
[11:47] <sil2100> bzoltan_: is there some new method of doing the -gles uploads, or is it the same as in the past?
[11:48] <bzoltan_> sil2100:  I do not know about any change... the last time I have landed the 1688 UITK I simple updated the changelog and added the MR, so without watch file
[11:49] <sil2100> bzoltan_: so changing the watch file is no longer required? Just want to get myself up-to-date with latest changes Robert made
[11:49] <bzoltan_> sil2100: Yes, that is the new thing .. no watch file
[11:56] <rvr> sil2100: Yes, krillin
[12:19] <jgdx> mardy, what's the target? OTA8?
[12:21] <mardy> jgdx: yes!
[12:21] <jgdx> mardy, wheee
[12:21] <jgdx> mardy, when testing that silo, could you make sure the header is shown in System Settings -> Online Accounts?
[12:22] <jgdx> if not, just let me know and we'll figure it out
[12:24] <mardy> jgdx: ok I will
[13:24] <boiko> sil2100: could you please remove wily packages from silos 25 and 54?
[13:33] <sil2100> boiko: on it!
[13:33] <sil2100> rvr: did it download?
[13:33] <boiko> sil2100: thanks!
[13:34] <sil2100> boiko: will you be re-building the silos? Since if they're both ready for release I can simply copy the wily packages to xenial
[13:34] <rvr> sil2100: Yes, it did
[13:34] <boiko> sil2100: none of them are ready for release
[13:35] <boiko> sil2100: well, silo 54 maybe, but on silo 25 we are expecting rebuilts to happen
[13:35] <sil2100> boiko: ok, then maybe it's safer to just remove the binaries then
[13:36] <boiko> sil2100: yep, I think it is better to rebuild the silos indeed
[13:36] <sil2100> boiko: done, yw!
[13:37] <boiko> sil2100: great! thanks
[13:59] <rvr> jgdx: http://people.canonical.com/~vrruiz/ubuntu-system-settings-ota-about.png
[13:59] <jgdx> uh
[14:00] <rvr> jgdx: The string is "OTA-x"
[14:01] <rvr> jgdx: version_detail: device=20150821-736d127,custom=20150925-901-35-40-vivid,keyring=archive-master,tag=OTA-x,version=
[14:01] <jgdx> rvr, what's the output of gdbus call -y -d com.canonical.SystemImage -o /Service -m com.canonical.SystemImage.Information
[14:02] <rvr> jgdx: ({'device_name': 'krillin', 'current_build_number': '2', 'last_check_date': '', 'channel_name': 'tag-test', 'version_detail': 'device=20150821-736d127,custom=20150925-901-35-40-vivid,keyring=archive-master,tag=OTA-x,version=2', 'target_build_number': '-1', 'last_update_date': '2015-10-29 13:07:36'},)
[14:03] <jgdx> rvr, so, on the previous screen, does it say OTA-x?
[14:04] <rvr> jgdx: Where?
[14:04] <jgdx> go back one,
[14:04] <rvr> Hmm
[14:04] <jgdx> rvr, how can I test this channel and image?
[14:04] <rvr> Wait a moment
[14:05] <rvr> The silo didn't install
[14:05] <rvr> jgdx: "Unavailable" should be translated
[14:06] <jgdx> rvr, yeah, that's bad.
[14:07]  * sil2100 hopes he didn't break anything by adding the tag as OTA-x
[14:07] <sil2100> Didn't want to put any confusion with an image with a real OTA tag
[14:09] <jgdx> sil2100, let's just get it right :) Thanks for providing the image. Do you have some steps I can do to install this image?
[14:13] <rvr> The following packages have been kept back:
[14:13] <rvr>   libsystemsettings1
[14:14] <jgdx> oh, yeah, maybe it prefers the newer stable overlay system settings?
[14:14] <sil2100> jgdx: I ran it on my private s-i server locally, I don't want to keep my ports open for too long
[14:15] <jgdx> rvr, you know what to do or do you want steps?
[14:15] <jgdx> sil2100, okay
[14:15] <jgdx> rvr, btw, I haven't changed "OS build number" to use the OTA. I can't remember the rationale for that, though.
[14:16] <sil2100> If you guys need it for testing tho, I can set it up on a canonistack instance temporarily
[14:16] <rvr> jgdx: sil2100 has a local server
[14:17] <rvr> jgdx: But it takes ages to download
[14:17] <jgdx> rvr, are you able to install the correct USS version?
[14:17] <rvr> sil2100: I have a faster connection, do you want me to upload the bits somewere?
[14:17] <rvr> somewhere
[14:17] <rvr> jgdx: Still trying
[14:17] <rvr> It refuses to do a dist-upgrade
[14:18] <jgdx> rvr, apt-cache policy ubuntu-system-settings and then install by apt-get install {libsystemsettings1,ubuntu-system-settings}=$version
[14:19] <jgdx> pick the version provided by the silo
[14:19] <rvr> jgdx: Ahh, the version of the stable ppa is higher that the one in the silo
[14:20] <jgdx> yes
[14:21] <rvr> jgdx: The following packages will be REMOVED:
[14:21] <rvr>   account-plugin-ubuntuone obexd-server ubuntu-system-settings
[14:21] <rvr>   ubuntu-system-settings-online-accounts ubuntu-touch ubuntu-touch-session
[14:22] <rvr> jgdx: http://paste.ubuntu.com/12999225/
[14:22] <rvr> jgdx: Looks ugly
[14:22] <rvr> jgdx: Status	SILO DIRTY: You must rebuild: ubuntu-system-settings
[14:23] <jgdx> aaah, okay, let's do a rebuild
[15:06] <dobey> rvr: can we get pay-ui/pay-service requests tested now? mardy's fix from yesterday is in the overlay ppa now, and these requests have been sitting here for a week now
[15:07] <rvr> dobey: This morning it wasn't available in the overlay PPA, but I'm checking other silos now.
[15:10] <dobey> rvr: is nobody else doing the qa sign off testing too? i see your face on a lot of cards, and not many others :-/
[15:12] <rvr> dobey: Right now, yes.
[15:18] <mardy> jgdx, rvr: silo 18 now fixes bug 1511055
[15:18] <jgdx> mardy, thank you
[15:19] <mardy> jgdx: I also merged your MP into the uitk 1.3 branch: https://code.launchpad.net/~jonas-drange/ubuntu-system-settings-online-accounts/lp1445350/+merge/271956
[15:19] <robru> bzoltan_: did you get your gles problem fixed? I'm around to look at it if it's still a problem. What silo?
[15:20] <rvr> mardy: Great
[15:21] <jgdx> mardy, thanks
[15:22] <alecu> rvr: jibel: sil2100: we screwed up, and forgot about the extra strings in the sound indicator bugfixes in silo 46. Still, I'm talking with xavigarcia and we'd like to know if it's possible to request an exception, since  there's an extra week for bugfixing this time, and that will give enough time for translators to get that done.
[15:23] <alecu> it's this card: https://trello.com/c/4fh6dI4j/2417-528-ubuntu-landing-046-indicator-sound-xavi-garcia-mena
[15:24] <mardy> jgdx: thanks to you :-)
[15:39] <bzoltan_> robru:  not yet
[15:39] <bzoltan_> robru: https://ci-train.ubuntu.com/job/ubuntu-landing-051-1-build/52/console
[15:43] <alecu> rvr: xavigarcia: I've got confirmation from jibel and pmcgowan that an exception is allowed for the strings in silo 46. So: we need to give a week before the final freeze for translators to work on this, and please xavigarcia, as soon as this lands let the -translators mailing list know about the new strings.
[15:43] <robru> bzoltan_: looks like the versions are out of sync, xenial build is building .1 but gles build is looking for .2 somehow. Maybe try a version bump in the upstream part of the version to force them to sync up again.
[15:43] <rvr> alecu: Ack
[15:44] <bzoltan_> robru:  I will try
[15:44] <rvr> jgdx: Build failed
[15:44] <alecu> rvr: thanks
[15:44] <jgdx> rvr, looking
[15:48] <jgdx> rvr, it didn't even try.. Let's do another.
[15:57] <robru> bzoltan_: oh it's probably because you put .1 in the changelog, so the train tried to increment that
[15:58] <robru> bzoltan_: you probably shouldn't touch the changelog manually anymore, just put your message in the mp "commit message" field, it will generate the changelog with right values.
[15:59] <robru> bzoltan_: or if you really need to touch the changelog just put "upstream-0ubuntu1" don't try to predict the date part, train will add that itself
[16:03] <bzoltan_> robru:  Okey, i push the gles branch again and see
[16:26] <rvr> dobey: There is a problem with this test "Security Information: Paypal payment"
[16:27] <rvr> dobey: When I tap cancel in the paypal login page, it shows a Ubuntu One login page
[16:27] <rvr> dobey: In stable, it goes back to the the app info screen, as expected
[16:33] <jgdx> rvr, okay, this uss build seems to be more successful
[16:36] <rvr> jgdx: Cool
[16:40] <dobey> rvr: huh.
[16:41] <Saviq> robru, is it expected that a unity8, qtmir, qtmir-gles rebuild would take almost 1.5h just to prepare packages https://ci-train.ubuntu.com/job/ubuntu-landing-021-1-build/232/consoleFull ?
[16:44] <Saviq> ah hmm, *2, because dual landing... still, 20mins to build a source package :/
[16:45] <sil2100> jibel, rvr: hey, you guys want to have the meeting today?
[16:51] <jibel> sil2100, I don't think it's necessary, there is nothing special
[16:51] <dobey> rvr: i get the same behavior for both, and apparently the paypal site itself is different now.
[16:52] <Saviq> sil2100, is devel-proposed xenial yet? or is there a different channel?
[16:56] <sil2100> Saviq: it's devel-proposed, good thing you mentioned as I see s-i didn't import the rootfs - let me do it now
[16:59] <dobey> hmm, actually the sandbox paypal site that we get via staging is different than the production site
[16:59] <dobey> sigh
[17:02] <robru> sil2100: I'm OK to skip
[17:02] <dobey> hmm, no on production it works correctly for me with both versions of payui
[17:02] <robru> Saviq: that does sound quite slow, not sure why though...
[17:03] <Saviq> robru, yeah, it doesn't help it doesn't log anything after "building...source package"
[17:04] <Saviq> or well, just spews in the whole log in one go
[17:05] <robru> Saviq: yeah i had to buffer the output of the source package build because when it was unbuffered it would print things out of order in a totally illegible way
[17:06] <Saviq> robru, :)
[17:06] <dobey> rvr: so this works fine for me, and none of the changed code is related to that. i'm not sure what you did, but it's working the same in both.
[17:07] <robru> Saviq: part of the problem seems to be that the chroots are old and installing a ton of updates. The job that periodically refreshes the chroots has been busted fit a while but it hasn't been a priority to fix
[17:08] <Saviq> robru, /me puts priority on it
[17:08] <Saviq> ;)
[17:09] <Saviq> robru, even if you can just do it one-off manually, every once in a while, would be good enough
[17:10] <robru> Saviq: unfortunately i can't, last time i looked at it the failure was quite mysterious. Like it was saying "file not found" or something, but the file clearly existed when i checked.
[17:10] <Saviq> :/
[17:11] <robru> Saviq: one thing we've been wanting to do is switch from pbuilder to sbuild, i was figuring id fix everything in the switch, unfortunately there's a lot of priorities right now
[17:14] <robru> Saviq: https://ci-train.ubuntu.com/job/upgrade-chroot/489/console yeah this has always been a mystery to me
[17:16] <Saviq> robru, I think that's expected, if cowcopy ever worked, steaks would've been much cheaper... and likely less greenhouse gases, too
[17:17] <robru> Heh
[17:50] <jgdx> rvr, built :)
[18:21] <robru> Saviq: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/revision/1185#citrain/jenkins-templates/upgrade-chroot.xml.tmpl well that was embarassingly easy to fix. let me know if your next build is any faster
[18:23] <robru> Saviq: although the update to the xenial pbuilder is tiny compared to the giant list of updates I saw in your build log, not sure what that's about.
[18:48] <robru> Saviq: on second look, seems like your builds just pull in a ton of deps. Did you add new deps recently?
[18:52] <Saviq> robru, I think the real problem is there's no Test-Depends: in debian/control
[18:52] <Saviq> robru, so our Build-Depends might indeed be excessive
[18:53] <Saviq> robru, or maybe even Source-Depends, as obviously building a source package does not require all of build-depends
[18:53] <robru> Saviq: is Source-Depends a thing? never heard of that one. it is a bit silly to pull in the entire world just to build a source package though
[18:53] <Saviq> robru, well, yeah, that's the problem, there isn't
[18:54] <robru> heh
[18:54] <Saviq> robru, yeah, well, if only there was a way to declare srcpkg depends (some need some specific dh- packages, for example)
[18:54] <Saviq> unity8 itself I don't think requires anything above build-essential
[19:01] <robru> Saviq: yeah this is a problem I've run into in the past. not sure why debian doesn't handle this better. not much we can do I guess
[19:03] <Saviq> robru, we could devise a custom addition to debian/control that the train would use
[19:03] <robru> Saviq: oh god pls no
[19:04] <robru> Saviq: the train-specific gles hackery is bad enough
[19:04] <Saviq> robru, oh well, I only meant X-Source-Depends or so
[19:04] <Saviq> robru, you'd use Build-Depends if not present, is al
[19:04] <Saviq> l
[19:05] <Saviq> robru, in any case, I'll have a look and see if we could clear this thing up
[19:06] <Saviq> robru, maybe we reduce Build-Depends to a minimum and add a debian/control.tests with Build-Depends listing test-only dependencies
[19:06] <Saviq> so that we can still use mk-build-deps on that or so
[19:06] <Saviq> we already have a bit of a split between build.sh and debian/control
[19:06] <Saviq> not a great situation indeed
[19:06] <robru> Saviq: yeah I'm not sure what to do about that
[19:08] <Saviq> robru, but I don't think X-Ubuntu-Source-Depends: would be such a bad idea, we have a bunch of custom bits for debian/control arleady
[19:08] <Saviq> even for the train (like the no-rewrite thing)
[19:09] <Saviq> robru, but yeah, a lot of our Build-Depends could probably be scrapped, we've been abusing it for test dependencies
[19:10] <Saviq> but then we'd have to duplicate it between debian/control.test and debian/tests/control :/
[19:10] <Saviq> meh meh meh
[19:10] <robru> yeah
[19:12]  * Saviq will talk with pitti tomorrow to see if they ever thought of that
[20:16] <kenvandine> wow... citrain spam :)
[20:17] <robru> kenvandine: yeah I don't know what the hell this is, I specifically coded queuebot not to spam on startup, but apparently there's some kind of network error causing it to parcially clear it's state, but not clear it enough to think it's starting fresh and suppress the startup spam.
[20:18] <robru> kenvandine: like, the state gets cleared enough that it thinks it needs to notify all this stuff, but doesn't clear enough that it realizes it's got no state and doing a fresh-startup spam
[20:18] <kenvandine> queuebot was hungry, need some spam to chew on :)
[20:21] <Saviq> cihelp, any reason we only have two makos online http://s-jenkins.ubuntu-ci:8080/label/mako/? ?
[20:23] <pmcgowan> Saviq, I have heard they are all dying
[20:23] <Saviq> :(
[20:23] <pmcgowan> so need to get some krillins instead
[20:25] <josepht> Saviq: what pmcgowan said, unfortunately
[21:26] <sil2100> cyphermox, mterry: hey! We have a few packages that would require core-devs for releasing :)
[21:26] <sil2100> cyphermox, mterry: https://requests.ci-train.ubuntu.com/#/publishable
[21:35] <robru> wat http://paste.ubuntu.com/13003129/
[21:36] <sil2100> ;p
[21:39] <mardy> sil2100: what is the problem with silo 56 and libaccounts-qt?
[21:39] <mterry> sil2100, looking
[21:40] <sil2100> mardy: nothing wrong so far, I'm just not powerful enough to publish that
[21:40] <sil2100> mterry: thanks!
[21:40] <sil2100> mardy: it needs a core-dev, I'm just a MOTU
[21:40] <sil2100> mterry: I'll take unity-scopes-shell, that's an universe package
[21:44] <sil2100> mterry: the mediascanner2 landing needs an archive admin btw.
[21:44] <sil2100> mterry: since it renames a package
[21:44] <sil2100> mterry: (just so you know)
[21:44] <sil2100> :)
[21:44] <mterry> sil2100, that doesn't affect publishing though right?  that's a post-publish step?
[21:44] <sil2100> mterry: it's actually a pre-publish step
[21:45] <mterry> sil2100, oh.  OK, will leave that one alone then
[21:45] <sil2100> mterry: since the train doesn't respect new binary packages, just pushes them without them going to the NEW queue
[21:45] <mterry> oh huh.  I didn't know we could shortcircuit NEW
[21:45] <sil2100> mterry: for new source packages - yes, but for new binary ones we need to poke some archive admin
[21:46] <sil2100> slangasek: hey! If you have a moment, there's a silo that needs an archive admin checking the binNEW -> https://ci-train.ubuntu.com/job/ubuntu-landing-031-2-publish/24/
[21:46] <slangasek> sil2100: looking
[21:46] <sil2100> brb
[21:50] <slangasek> sil2100: isn't this package missing Conflicts/Replaces from qml-module-ubuntu-mediascanner0.1 against the old version of qtdeclarative5-ubuntu-mediascanner0.1?  It looks to me that the package will fail to upgrade, which is more important than the transitional package issue
[21:50] <slangasek> sil2100: it's ok from an AA POV but not from a core-dev signoff
[21:53] <mterry> sil2100, silo 56 looks fine packaging wise, but needs to incorporate the archive changes above ^
[21:54]  * mterry goes afk for a few minutes
[22:33] <robru> holy hell, silo 56 wasn't built since before the gcc transition??
[22:35] <michi> robru: What’s with the flood of notifications anyway?
[22:35] <robru> michi: queuebot is a braindead piece of crap
[22:35] <michi> I haven’t built anything since yesterday, and now I’m being told that the build has finished
[22:35] <michi> Ah, that explains it then :)
[22:36] <robru> michi: I don't know why or how, but I'm told that queuebot is experiencing some sort of network error that causes it to lose all it's state (so it thinks all those statuses are new and need to be pinged), but it doesn't lose ALL of it's state, otherwise it would hit the piece of code I wrote that says "hey if there's no state, don't spam the channel"
[22:37] <michi> Oh well, it’s not the end of the world. There are bugs worse than this :)
[22:37] <robru> yeah