=== yofel_ is now known as yofel [09:06] infinity: not sure if you noticed, but: https://lists.canonical.com/archives/utopic-changes/2014-May/002158.html [09:06] so now, you have attribution to the guy pushing the "publish" button or for who the packaging/integration ack was sponsored for [09:11] didrocks: \o/ [09:13] infinity, you see that as an improvement? [09:13] 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] seb128: yes, it used to be "robot uploads" not it's "Timo uploaded, sponsored by robot" [09:14] s/not/now/ [09:14] infinity, because seeing the landing from today have all the wrong owners [09:14] they have the CI team guy who did push buttons [09:14] not the people who put the landing/tested it/asked it to land [09:14] The "uploader" is the responsible person for an upload. [09:14] it's stealing credit and pointing the blame to the wrong person [09:14] They shouldn't push the button if they don't want the responsibility. [09:15] seb128: well, infinity get's a person to chase down and receive reject emails from the queue =) [09:15] This is no different than sponsoring patches, which you do a lot. [09:15] I often keep the name in the changelog [09:15] and design with my key [09:15] I don't rename the changelog to steal credit [09:15] you have changed-by and signed-by [09:15] There's no "stealing credit" here. [09:16] there is [09:16] when I sponsor something, the -changes email has the name of the person who did the work/own the changelog entry [09:16] I'm only the signer [09:17] 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] Okay, so that's a process fail in the CI stuff. The person requesting the upload should actually relate to the changes. [09:17] stgraber, ^ I've been told you are the one against doing that, why? [09:17] infinity: but they are not the one acking the pakaging change though [09:17] seb128: didrocks had been planning to have it attribute to the correct person; I don't know why that isn't happening [09:17] packaging* [09:18] (Or I misunderstood) [09:18] cjwatson: with the discussion we had with stgraber, it was clear it needed to be the guy publishing the package [09:18] not the lander [09:18] as they took responsability with the packaging ack [09:19] and they are the ones on the road to get motu/more packaging upload access [09:19] so, I really don't care [09:19] just be in agreement [09:19] I don't feel that strongly either way; having any contact at all is better than none [09:19] Anyone is better than the bot, as long as there's a blame trail. [09:19] but don't turn around on criterias please [09:19] But it would be nice if the blame was going to an appropriate place, whatever that place is. [09:19] I'm in no position to say, really, who that should be. [09:19] (criteria; the singular is criterion) [09:20] infinity: right, that's exactly my position [09:20] (cjwatson: ok, at least that discussion will teach me that :)) [09:21] infinity: seb128: -changes emails are wrong for all syncs, no?! [09:22] 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] xnox, no, autosync don't end up on -changes, and syncpackage has a -s argument [09:22] so… I just want you guys to come to a conclusion, it's either: [09:22] - the guy pushing the publish button [09:22] - the first lander listed for a request [09:23] I don't care either way, just take a decision, I'll implement the change if it's the second [09:23] didrocks, thanks, and sorry for the discussion [09:23] I just don't want that to be turn in and back [09:23] seb128: the -s argument was used here, as far as i can tell. [09:23] (both are easily to switch to now) [09:23] xnox, right, it's just that stgraber requested that the name to be used is the one who push the publish button [09:23] not to lander/owner of the landing [09:23] didrocks: it should be the person who has upload rights, thus it should be the person who pushes the publish button. [09:24] didrocks: this is me talking as an DMB. [09:24] ok, wfm [09:24] 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] I'm just going to tell the CI team to stop pushing the publish button for me [09:24] :p [09:25] like when seb128 is sponsoring any community member [09:25] (some of them are eager to do that) [09:25] it's better to get to the point where people are doing that themselves anyway [09:25] seb128: Arguably, the button should be pushed by non-CI people anyway. [09:25] yeah, it's just that some CI lander jump on anything "ready to publish" [09:25] And if we start coming to CI people and blaming them for uploads, they'll learn that. :P [09:25] I had the general understanding that having a team of people whose job is to push buttons on things isn't ideal :) [09:25] right [09:25] well, the process works fine [09:25] (yeah, I know it's rather more than that ...) [09:25] Sponsors should always be prepared to be responsible for 100% of the changes they upload. [09:25] as said, just some people are eager to click on anything [09:26] 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] xnox: not about the guy taking the test responsability [09:26] who is the lander [09:27] xnox, well, I would like to be the one owning/be pinged for things I land [09:27] didrocks: true, but that's a ci-train type of role, for which there is no mapping in an soyuz upload record. [09:27] even if e.g sil2100 pressed publish for me [09:27] because I was not around and they wanted to get things moving [09:27] didrocks: but i presume the push-the-button person to know who the lander was. [09:27] seb128: they can push the button, but attribute it to you, I added a field for that [09:27] didrocks: or add a changelog entry "Lander: mark" [09:27] xnox: yeah, that's recorded [09:27] Indeed o/ [09:27] not in the changelog [09:28] didrocks, ok, seemed easier to take the lander in my view, but I guess that works too ;-) [09:28] didrocks: yeah, if it's recorded anywhere, that's sufficient. [09:28] didrocks: no need to duplicate it anywhere else. [09:28] 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] didrocks: everything looks good at the moment, no changes needed, let's gather more feedback. [09:29] +1 [09:33] xnox: (can't go in the changelog because the packages are already built at the time somebody pushes the publish button) [09:35] 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] cjwatson: oh, I didn't pull it? sorry, I thought I did [09:36] cjwatson: yeah, I stupidely forgot to save the file during the checking… [09:36] 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] Maybe I'm looking in the wrong place ... [09:37] cjwatson: unfortunately, I never took the time to look at why it was never published to the ML list [09:37] cjwatson: but anyway, should be in somewhere more central now than ubuntu-unity [09:38] oh right, I forgot to pull on the publisher-side :/ [09:38] We could just do what proposed-migration does: write out timestamped log files visible on http://people.canonical.com/~ubuntu-archive/somewhere [09:39] cjwatson: yeah, sounds sane, I can add that to my backlog and do it [09:39] great, thanks [09:40] thanks for pulling yesterday :) [10:46] hm, is britney not running, even though there are ADT test results, because there is no archive movements at the moment? [10:47] That would probably be usual, but I can run it manually if that would help [10:47] can we just cron britney to e.g. run at least every hour, if it hasn't otherwise run? [10:47] cjwatson: please trigger it, i think sysvinit should migrate. [10:47] Maybe but I'm not going to engage in major refactoring just before going on leave for the afternoon :) [10:47] running [10:48] =))))) [10:50] Apparently not quite; linux and mysql-5.6 still running [10:51] Hopefully close though. I'll watch those and re-run when they're done [10:54] 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] linux however, has started to pass, so we'd need to wait for that one. [10:55] For something like sysvinit I'd really rather let the tools get to the point where they're happy [10:55] true. [10:56] Opportunity to test my livefs building setup against -proposed ... === seb128_ is now known as seb128 [11:11] xnox: cronning britney isn't the answer, triggering it is, it's on my TODO. [11:12] 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] Neither the linux nor the mysql-5.6 test has moved in a while ... [11:12] pitti: ^- can you tell if those two are actually doing anything? [11:13] checking [11:15] linux is at copying the source tree (which is just effing big); there's visible progress on albali [11:16] 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] OK [11:16] As long as it's moving [11:17] mysql> yeah, we really need live output; it's quite tricky to do through qemu, but it's on my list [11:17] logging into the VM [11:21] cjwatson: and there's also visible progress on mysql === michagogo|cloud is now known as michagogo [13:24] bdmurray: sure I'll update the wiki. === doko_ is now known as doko [14:21] 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] or infinity ^^^ [14:26] cjwatson, infinity: do you know why fonts-indic is not in Ubuntu? [14:28] 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] thanks [14:29] looks like the builders finished fine [14:29] ubuntu-touch-i386 on cardamom.buildd finished at 2014-05-16 13:26:48 (success) [14:29] ubuntu-touch-armhf on kishi00.buildd finished at 2014-05-16 13:58:32 (success) [14:29] Traceback (most recent call last): [14:29] ,,,, [14:29] File "/usr/lib/python2.7/xmlrpclib.py", line 793, in close [14:29] raise Fault(**self._stack[0]) [14:29] Fault: [14:29] thats what i got [14:29] oh, wait ... you too :P [14:29] * ogra_ sees the CC list [14:30] right, that's the qatracker causing a build failure [14:30] looks like the tracker database is down or something... [14:30] * stgraber investigates [14:30] doko: ttf-indic-fonts? [14:31] stgraber, well, we had all builds failing tonight (and throughout the day) i assume thats some fallout [14:31] (all arches, all flavours) [14:32] wtf, all drupal plugins got disabled somehow [14:32] lovely [14:32] I suspect IS tried to apply some updates without contacting me and blew up the drupal setup [14:32] 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] i started the build via the qa tracker ... [14:32] just FYI [14:33] back then it worked fine [14:33] so the tracker is sort of back online (modules re-enabled but read-only fs so it's pretty ugly) [14:34] stgraber, think a build would survive ? [14:34] * ogra_ doesnt want to start one if it will fail anyway [14:35] ogra_: the API seems fine, so probably worth a shot, I'm working IS to fix whatever broke [14:35] ok, starting a touch build (again) [14:51] hmm, i wonder where that 14:29 build failure came from ... [14:51] i surely started my build later [14:52] * ogra_ guesses the ttracker had some state cached or so [14:58] 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] stgraber, thanks a lot [15:35] build worked btw [16:29] infinity, please guide new utopic 3.15 kernel packages to the appropriate place in main when they are done building. [16:42] Oops I should have had an arch restriction === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [17:54] 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] and the -android once should be sufficient. [18:10] xnox: possibly a question of dependency traversal ordering [18:11] what depends on libmirclientplatform-mesa, and is it something that's listed in the seed earlier than libmirclientplatform-android? [18:12] xnox, iirc tasks resolve deps in reverse order to apt-get ... [18:12] we had such an issue with java a while ago [18:12] slangasek: yes. shall i move libmir*-mesa to the top or to the bottom of the seed then? [18:12] xnox: you mean -android? [18:12] if you switch the | dep in the package it will obey to the seed [18:12] slangasek: yes. [18:12] xnox: top [18:12] slangasek: ack. [18:13] (or at least, "above the thing whose dep order you need to override") [18:14] slangasek: next we have on libqt5gui5:armhf depending on "libegl1-mesa (>= 7.8.1) | libegl1-x11" [18:14] 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] 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] it pulls in llvm3.4 on to touch images =) [18:15] xnox: we have that dep because that's what the shlibdeps of libegl1 say? [18:16] is there another package installed as part of the image that should satisfy the dep without pulling in the mesa version? [18:16] IIRC the trick here was that the alternative provider was part of the device image, not the rootfs [18:20] 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] ogra_: i don't want to flip that. we have far more mesa based mir installations then android. [18:20] we had this issue before ... more than once [18:21] ogra_: yes, and then you would break the other unity8 image instead [18:21] ogra_: bubbling up -android in the seed is the cleanest way, instead of playing a whack-a-mole. [18:21] iirc for the case where you cant flip there are/were hacks in livecd-rootfs [18:21] the right way to specify which provider of a dep you want is to explicitly seed it first [18:23] hmm, all gone from the code nowadays ... there is a way to specify extra packages per flavour [18:23] i know we used that for a bunch of arm builds [18:23] livecd-rootfs is the wrong place to specify that for official builds; it belongs in the seed [18:24] ah, right it was add_package() ... in live-build/auto/config [18:24] right, as i said, hacks :) [18:32] 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] 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] 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] arges: trusty is where it's needed. That delta can be dropped in utopic again. [18:55] infinity: so should i make a note of that somewhere? or just wait until utopic gets synced over [18:55] 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] or merged over rather [18:56] 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] 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] infinity: ok i'll note that in the bug. thanks [19:21] 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] slangasek: could you have a look at apport in the trusty -proposed queue? [23:05] bdmurray: looking [23:08] thanks