[09:06] <didrocks> infinity: not sure if you noticed, but: https://lists.canonical.com/archives/utopic-changes/2014-May/002158.html
[09:06] <didrocks> so now, you have attribution to the guy pushing the "publish" button or for who the packaging/integration ack was sponsored for
[09:11] <infinity> didrocks: \o/
[09:13] <seb128> infinity, you see that as an improvement?
[09:13] <infinity> seb128: How is it not?  Having thousands of uploads attributed to a bot that can't be harassed when there are problems is worthless.
[09:14] <xnox> seb128: yes, it used to be "robot uploads" not it's "Timo uploaded, sponsored by robot"
[09:14] <xnox> s/not/now/
[09:14] <seb128> infinity, because seeing the landing from today have all the wrong owners
[09:14] <seb128> they have the CI team guy who did push buttons
[09:14] <seb128> not the people who put the landing/tested it/asked it to land
[09:14] <infinity> The "uploader" is the responsible person for an upload.
[09:14] <seb128> it's stealing credit and pointing the blame to the wrong person
[09:14] <infinity> They shouldn't push the button if they don't want the responsibility.
[09:15] <xnox> seb128: well, infinity get's a person to chase down and receive reject emails from the queue =)
[09:15] <infinity> This is no different than sponsoring patches, which you do a lot.
[09:15] <seb128> I often keep the name in the changelog
[09:15] <seb128> and design with my key
[09:15] <seb128> I don't rename the changelog to steal credit
[09:15] <seb128> you have changed-by and signed-by
[09:15] <infinity> There's no "stealing credit" here.
[09:16] <seb128> there is
[09:16] <seb128> when I sponsor something, the -changes email has the name of the person who did the work/own the changelog entry
[09:16] <seb128> I'm only the signer
[09:17] <seb128> it would make more sense to use the name of who is listed as "lander" for the corresponding line in the CI table
[09:17] <infinity> Okay, so that's a process fail in the CI stuff.  The person requesting the upload should actually relate to the changes.
[09:17] <seb128> stgraber, ^ I've been told you are the one against doing that, why?
[09:17] <didrocks> infinity: but they are not the one acking the pakaging change though
[09:17] <cjwatson> seb128: didrocks had been planning to have it attribute to the correct person; I don't know why that isn't happening
[09:17] <didrocks> packaging*
[09:18] <cjwatson> (Or I misunderstood)
[09:18] <didrocks> cjwatson: with the discussion we had with stgraber, it was clear it needed to be the guy publishing the package
[09:18] <didrocks> not the lander
[09:18] <didrocks> as they took responsability with the packaging ack
[09:19] <didrocks> and they are the ones on the road to get motu/more packaging upload access
[09:19] <didrocks> so, I really don't care
[09:19] <didrocks> just be in agreement
[09:19] <cjwatson> I don't feel that strongly either way; having any contact at all is better than none
[09:19] <infinity> Anyone is better than the bot, as long as there's a blame trail.
[09:19] <didrocks> but don't turn around on criterias please
[09:19] <infinity> But it would be nice if the blame was going to an appropriate place, whatever that place is.
[09:19] <infinity> I'm in no position to say, really, who that should be.
[09:19] <cjwatson> (criteria; the singular is criterion)
[09:20] <cjwatson> infinity: right, that's exactly my position
[09:20] <didrocks> (cjwatson: ok, at least that discussion will teach me that :))
[09:21] <xnox> infinity: seb128: -changes emails are wrong for all syncs, no?!
[09:22] <xnox> infinity: seb128: https://launchpad.net/ubuntu/utopic/+source/qtcreator-plugin-ubuntu/3.0.1+14.10.20140516-0ubuntu1 clearly has Timo as uploader, sponsored by robot, copied from -proposed -> -release by robot.
[09:22] <seb128> xnox, no, autosync don't end up on -changes, and syncpackage has a -s argument
[09:22] <didrocks> so… I just want you guys to come to a conclusion, it's either:
[09:22] <didrocks> - the guy pushing the publish button
[09:22] <didrocks> - the first lander listed for a request
[09:23] <didrocks> I don't care either way, just take a decision, I'll implement the change if it's the second
[09:23] <seb128> didrocks, thanks, and sorry for the discussion
[09:23] <didrocks> I just don't want that to be turn in and back
[09:23] <xnox> seb128: the -s argument was used here, as far as i can tell.
[09:23] <didrocks> (both are easily to switch to now)
[09:23] <seb128> xnox, right, it's just that stgraber requested that the name to be used is the one who push the publish button
[09:23] <seb128> not to lander/owner of the landing
[09:23] <xnox> didrocks: it should be the person who has upload rights, thus it should be the person who pushes the publish button.
[09:24] <xnox> didrocks: this is me talking as an DMB.
[09:24] <seb128> ok, wfm
[09:24] <didrocks> xnox: well, you still sponsor for someone else… like we want sil2100 to get some credits of his reviewing and packaging work for instance
[09:24] <seb128> I'm just going to tell the CI team to stop pushing the publish button for me
[09:24] <seb128> :p
[09:25] <didrocks> like when seb128 is sponsoring any community member
[09:25] <seb128> (some of them are eager to do that)
[09:25] <cjwatson> it's better to get to the point where people are doing that themselves anyway
[09:25] <infinity> seb128: Arguably, the button should be pushed by non-CI people anyway.
[09:25] <seb128> yeah, it's just that some CI lander jump on anything "ready to publish"
[09:25] <infinity> And if we start coming to CI people and blaming them for uploads, they'll learn that. :P
[09:25] <cjwatson> I had the general understanding that having a team of people whose job is to push buttons on things isn't ideal :)
[09:25] <seb128> right
[09:25] <seb128> well, the process works fine
[09:25] <cjwatson> (yeah, I know it's rather more than that ...)
[09:25] <infinity> Sponsors should always be prepared to be responsible for 100% of the changes they upload.
[09:25] <seb128> as said, just some people are eager to click on anything
[09:26] <xnox> didrocks: so, in the changelog i see who made the changes, robot did the upload, the reviewer/publisher (person with upload rights) is the one pushing the button. so i have all the information as to who did what, no?!
[09:26] <didrocks> xnox: not about the guy taking the test responsability
[09:26] <didrocks> who is the lander
[09:27] <seb128> xnox, well, I would like to be the one owning/be pinged for things I land
[09:27] <xnox> didrocks: true, but that's a ci-train type of role, for which there is no mapping in an soyuz upload record.
[09:27] <seb128> even if e.g sil2100 pressed publish for me
[09:27] <seb128> because I was not around and they wanted to get things moving
[09:27] <xnox> didrocks: but i presume the push-the-button person to know who the lander was.
[09:27] <didrocks> seb128: they can push the button, but attribute it to you, I added a field for that
[09:27] <xnox> didrocks: or add a changelog entry "Lander: mark"
[09:27] <didrocks> xnox: yeah, that's recorded
[09:27] <sil2100> Indeed o/
[09:27] <didrocks> not in the changelog
[09:28] <seb128> didrocks, ok, seemed easier to take the lander in my view, but I guess that works too ;-)
[09:28] <xnox> didrocks: yeah, if it's recorded anywhere, that's sufficient.
[09:28] <xnox> didrocks: no need to duplicate it anywhere else.
[09:28] <didrocks> anyway, I don't want to jump to that discussion, just be in agreement with some plan, I'll do whatever changes are needed if you feel so
[09:29] <xnox> didrocks: everything looks good at the moment, no changes needed, let's gather more feedback.
[09:29] <seb128> +1
[09:33] <cjwatson> xnox: (can't go in the changelog because the packages are already built at the time somebody pushes the publish button)
[09:35] <cjwatson> didrocks: Oh, I forgot to send e-mail - I deployed r594 of cupstream2distro last night (was r592) because the citrain publisher was crashing due to the lack of the get_person implementation that you did in r594
[09:35] <didrocks> cjwatson: oh, I didn't pull it? sorry, I thought I did
[09:36] <didrocks> cjwatson: yeah, I stupidely forgot to save the file during the checking…
[09:36] <cjwatson> didrocks: Is there a way to see the logs other than just running it by hand (which is what I did in the end)?  The crontab says MAILTO=ubuntu-unity@lists.launchpad.net, but https://lists.launchpad.net/ubuntu-unity/ is empty
[09:36] <cjwatson> Maybe I'm looking in the wrong place ...
[09:37] <didrocks> cjwatson: unfortunately, I never took the time to look at why it was never published to the ML list
[09:37] <didrocks> cjwatson: but anyway, should be in somewhere more central now than ubuntu-unity
[09:38] <didrocks> oh right, I forgot to pull on the publisher-side :/
[09:38] <cjwatson> We could just do what proposed-migration does: write out timestamped log files visible on http://people.canonical.com/~ubuntu-archive/somewhere
[09:39] <didrocks> cjwatson: yeah, sounds sane, I can add that to my backlog and do it
[09:39] <cjwatson> great, thanks
[09:40] <didrocks> thanks for pulling yesterday :)
[10:46] <xnox> hm, is britney not running, even though there are ADT test results, because there is no archive movements at the moment?
[10:47] <cjwatson> That would probably be usual, but I can run it manually if that would help
[10:47] <xnox> can we just cron britney to e.g. run at least every hour, if it hasn't otherwise run?
[10:47] <xnox> cjwatson: please trigger it, i think sysvinit should migrate.
[10:47] <cjwatson> Maybe but I'm not going to engage in major refactoring just before going on leave for the afternoon :)
[10:47] <cjwatson> running
[10:48] <xnox> =)))))
[10:50] <cjwatson> Apparently not quite; linux and mysql-5.6 still running
[10:51] <cjwatson> Hopefully close though.  I'll watch those and re-run when they're done
[10:54] <xnox> cjwatson: hm, mysql-5.6 should be in "always-failed" state now? even though it's currently-running, because it is "always-failed" the outcome of the currently running test is irrelevant.
[10:54] <xnox> linux however, has started to pass, so we'd need to wait for that one.
[10:55] <cjwatson> For something like sysvinit I'd really rather let the tools get to the point where they're happy
[10:55] <xnox> true.
[10:56] <cjwatson> Opportunity to test my livefs building setup against -proposed ...
[11:11] <infinity> xnox: cronning britney isn't the answer, triggering it is, it's on my TODO.
[11:12] <infinity> xnox: As for ignoring "always failed" while it's still running, that's just you being impatient.  If it started succeeding, we wouldn't ignore it anymore, right? :)
[11:12] <cjwatson> Neither the linux nor the mysql-5.6 test has moved in a while ...
[11:12] <cjwatson> pitti: ^- can you tell if those two are actually doing anything?
[11:13] <pitti> checking
[11:15] <pitti> linux is at copying the source tree (which is just effing big); there's visible progress on albali
[11:16] <pitti> albali's disks aren't the fastest on earth; but linux only started 2 hours 10 mins ago, the previous one took 2:55
[11:16] <cjwatson> OK
[11:16] <cjwatson> As long as it's moving
[11:17] <pitti> mysql> yeah, we really need live output; it's quite tricky to do through qemu, but it's on my list
[11:17] <pitti> logging into the VM
[11:21] <pitti> cjwatson: and there's also visible progress on mysql
[13:24] <arges> bdmurray: sure I'll update the wiki.
[14:21] <ogra_> stgraber, help ! ... do you know where cdimage sets a lock file ? i get an error for build_image_set_locked when trying to build a touch image ... looks like some stale file from failed builds tonight
[14:22] <ogra_> or infinity ^^^
[14:26] <doko> cjwatson, infinity: do you know why fonts-indic is not in Ubuntu?
[14:28] <stgraber> ogra_: there are a few, the most annoying one is on the actual builder and requires IS to clean it up, let me take a quick look
[14:28] <ogra_> thanks
[14:29] <ogra_> looks like the builders finished fine
[14:29] <ogra_> ubuntu-touch-i386 on cardamom.buildd finished at 2014-05-16 13:26:48 (success)
[14:29] <ogra_> ubuntu-touch-armhf on kishi00.buildd finished at 2014-05-16 13:58:32 (success)
[14:29] <ogra_> Traceback (most recent call last):
[14:29] <ogra_> ,,,,
[14:29] <ogra_>   File "/usr/lib/python2.7/xmlrpclib.py", line 793, in close
[14:29] <ogra_>     raise Fault(**self._stack[0])
[14:29] <ogra_> Fault: <Fault -32601: 'Server error. Requested method qatracker.get_access not specified.'>
[14:29] <ogra_> thats what i got
[14:29] <ogra_> oh, wait ... you too :P
[14:29]  * ogra_ sees the CC list
[14:30] <stgraber> right, that's the qatracker causing a build failure
[14:30] <stgraber> looks like the tracker database is down or something...
[14:30]  * stgraber investigates
[14:30] <Laney> doko: ttf-indic-fonts?
[14:31] <ogra_> stgraber, well, we had all builds failing tonight (and throughout the day) i assume thats some fallout
[14:31] <ogra_> (all arches, all flavours)
[14:32] <stgraber> wtf, all drupal plugins got disabled somehow
[14:32] <ogra_> lovely
[14:32] <stgraber> I suspect IS tried to apply some updates without contacting me and blew up the drupal setup
[14:32] <doko> Laney, http://packages.qa.debian.org/t/ttf-indic-fonts.html is a dummy package, and http://packages.qa.debian.org/f/fonts-indic.html is not in Ubuntu
[14:32] <ogra_> i started the build via the qa tracker ...
[14:32] <ogra_> just FYI
[14:33] <ogra_> back then it worked fine
[14:33] <stgraber> so the tracker is sort of back online (modules re-enabled but read-only fs so it's pretty ugly)
[14:34] <ogra_> stgraber, think a build would survive ?
[14:34]  * ogra_ doesnt want to start one if it will fail anyway
[14:35] <stgraber> ogra_: the API seems fine, so probably worth a shot, I'm working IS to fix whatever broke
[14:35] <ogra_> ok, starting a touch build (again)
[14:51] <ogra_> hmm, i wonder where that 14:29 build failure came from ...
[14:51] <ogra_> i surely started my build later
[14:52]  * ogra_ guesses the ttracker had some state cached or so
[14:58] <stgraber> the tracker should now be back to its usual state, a code+DB security upgrade from IS + a broken apparmor profile caused quite a bit of trouble but it looks like we've figured it all out now
[15:00] <ogra_> stgraber, thanks a lot
[15:35] <ogra_> build worked btw
[16:29] <rtg> infinity, please guide new utopic 3.15 kernel packages to the appropriate place in main when they are done building.
[16:42] <Laney> Oops I should have had an arch restriction
[17:54] <xnox> i need help with seeds. I'm failing to figure out why ubuntu-touch armhf has libmirplatformgraphics-mesa & libmirclientplatform-mesa installed, when libmirclientplatform-android & libmirplatformgraphics-android are seeded
[17:55] <xnox> and the -android once should be sufficient.
[18:10] <slangasek> xnox: possibly a question of dependency traversal ordering
[18:11] <slangasek> what depends on libmirclientplatform-mesa, and is it something that's listed in the seed earlier than libmirclientplatform-android?
[18:12] <ogra_> xnox, iirc tasks resolve deps in reverse order to apt-get ...
[18:12] <ogra_> we had such an issue with java a while ago
[18:12] <xnox> slangasek: yes. shall i move libmir*-mesa to the top or to the bottom of the seed then?
[18:12] <slangasek> xnox: you mean -android?
[18:12] <ogra_> if you switch the | dep in the package it will obey to the seed
[18:12] <xnox> slangasek: yes.
[18:12] <slangasek> xnox: top
[18:12] <xnox> slangasek: ack.
[18:13] <slangasek> (or at least, "above the thing whose dep order you need to override")
[18:14] <xnox> slangasek: next we have on libqt5gui5:armhf depending on "libegl1-mesa (>= 7.8.1) | libegl1-x11"
[18:14] <ogra_> xnox, please be very very careful what changes you make right now we are all working after hours to get a wroking image with build 34 again after two days of total breakage
[18:14] <xnox> slangasek: as far as i can see libegl1-x11 has only one provider, which is libegl1-mesa -> any clue as to why we have such a dep on a core qt library?
[18:15] <xnox> it pulls in llvm3.4 on to touch images =)
[18:15] <slangasek> xnox: we have that dep because that's what the shlibdeps of libegl1 say?
[18:16] <slangasek> is there another package installed as part of the image that should satisfy the dep without pulling in the mesa version?
[18:16] <slangasek> IIRC the trick here was that the alternative provider was part of the device image, not the rootfs
[18:20] <xnox> slangasek: is libhybris a reasonable provider of libgl1 & libegl1-x11 =)?
[18:20]  * xnox will build a test dummy-package and check if the image is still functional.
[18:20]  * ogra_ bets a monthly loan that if you make "libmirclientplatform-mesa | libmirclientplatform-android" to be  "libmirclientplatform-android | libmirclientplatform-mesa" in libmirclient the mesa deps will be gone from the touch image ... 
[18:20] <xnox> ogra_: i don't want to flip that. we have far more mesa based mir installations then android.
[18:20] <ogra_> we had this issue before ... more than once
[18:21] <slangasek> ogra_: yes, and then you would break the other unity8 image instead
[18:21] <xnox> ogra_: bubbling up -android in the seed is the cleanest way, instead of playing a whack-a-mole.
[18:21] <ogra_> iirc for the case where you cant flip there are/were hacks in livecd-rootfs
[18:21] <slangasek> the right way to specify which provider of a dep you want is to explicitly seed it first
[18:23] <ogra_> hmm, all gone from the code nowadays ... there is a way to specify extra packages per flavour
[18:23] <ogra_> i know we used that for a bunch of arm builds
[18:23] <slangasek> livecd-rootfs is the wrong place to specify that for official builds; it belongs in the seed
[18:24] <ogra_> ah, right it was add_package() ... in live-build/auto/config
[18:24] <ogra_> right, as i said, hacks :)
[18:32] <infinity> doko: Looks like it was blacklisted long ago.  Probably not required anymore.  I'll go through the blacklisted fonts and see what's bogus.
[18:54] <arges> stgraber: infinity : hey i'm trying to review open-vm-tools-hwe , bug 1275656. it introduces the new package for precise and a patch for trusty that transitions the package out. should i sponsor this for trusty even though it will be copied to utopic as well?
[18:54] <infinity> doko: Oh.  Those blacklists aren't bogus.  We're carrying a hefty delta to the source package that used to build those fonts (ttf-indic-fonts) that includes udebs.  Someone needs to put the time into porting that over to all the split packages.
[18:55] <infinity> arges: trusty is where it's needed.  That delta can be dropped in utopic again.
[18:55] <arges> infinity: so should i make a note of that somewhere? or just wait until utopic gets synced over
[18:55] <infinity> arges: The idea is that if they're giving people a fancy HWE version in precise, precise+trusty -> trusty upgrades need to work.
[18:55] <arges> or merged over rather
[18:56] <arges> infinity: yup i checked this, but then I just realized that utopic/trusty were at the same version and didn't want to mess up utopic
[18:57] <infinity> arges: It can be synced to utopic.  There's no harm in the cruft being there.  But the end result should be a utopic version that's higher and has that transitional package removed again.
[18:57] <arges> infinity: ok i'll note that in the bug. thanks
[19:21] <cjwatson> doko: yeah, exactly what infinity said - I tried once or twice to port the delta over but it was a multi-hour job
[22:44] <bdmurray> slangasek: could you have a look at apport in the trusty -proposed queue?
[23:05] <slangasek> bdmurray: looking
[23:08] <bdmurray> thanks