| === yofel_ is now known as yofel | ||
| 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:06 |
| infinity | didrocks: \o/ | 09:11 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| cjwatson | infinity: right, that's exactly my position | 09:20 |
| didrocks | (cjwatson: ok, at least that discussion will teach me that :)) | 09:20 |
| xnox | infinity: seb128: -changes emails are wrong for all syncs, no?! | 09:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| xnox | didrocks: everything looks good at the moment, no changes needed, let's gather more feedback. | 09:29 |
| seb128 | +1 | 09:29 |
| cjwatson | xnox: (can't go in the changelog because the packages are already built at the time somebody pushes the publish button) | 09:33 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| didrocks | cjwatson: yeah, sounds sane, I can add that to my backlog and do it | 09:39 |
| cjwatson | great, thanks | 09:39 |
| didrocks | thanks for pulling yesterday :) | 09:40 |
| xnox | hm, is britney not running, even though there are ADT test results, because there is no archive movements at the moment? | 10:46 |
| 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:47 |
| xnox | =))))) | 10:48 |
| cjwatson | Apparently not quite; linux and mysql-5.6 still running | 10:50 |
| cjwatson | Hopefully close though. I'll watch those and re-run when they're done | 10:51 |
| 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:54 |
| 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:55 |
| cjwatson | Opportunity to test my livefs building setup against -proposed ... | 10:56 |
| === seb128_ is now known as seb128 | ||
| infinity | xnox: cronning britney isn't the answer, triggering it is, it's on my TODO. | 11:11 |
| 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:12 |
| pitti | checking | 11:13 |
| pitti | linux is at copying the source tree (which is just effing big); there's visible progress on albali | 11:15 |
| 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:16 |
| 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:17 |
| pitti | cjwatson: and there's also visible progress on mysql | 11:21 |
| === michagogo|cloud is now known as michagogo | ||
| arges | bdmurray: sure I'll update the wiki. | 13:24 |
| === doko_ is now known as doko | ||
| 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:21 |
| ogra_ | or infinity ^^^ | 14:22 |
| doko | cjwatson, infinity: do you know why fonts-indic is not in Ubuntu? | 14:26 |
| 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:28 |
| 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:29 | |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| ogra_ | stgraber, think a build would survive ? | 14:34 |
| * ogra_ doesnt want to start one if it will fail anyway | 14:34 | |
| 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:35 |
| ogra_ | hmm, i wonder where that 14:29 build failure came from ... | 14:51 |
| ogra_ | i surely started my build later | 14:51 |
| * ogra_ guesses the ttracker had some state cached or so | 14:52 | |
| 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 | 14:58 |
| ogra_ | stgraber, thanks a lot | 15:00 |
| ogra_ | build worked btw | 15:35 |
| rtg | infinity, please guide new utopic 3.15 kernel packages to the appropriate place in main when they are done building. | 16:29 |
| Laney | Oops I should have had an arch restriction | 16:42 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| 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:54 |
| xnox | and the -android once should be sufficient. | 17:55 |
| slangasek | xnox: possibly a question of dependency traversal ordering | 18:10 |
| slangasek | what depends on libmirclientplatform-mesa, and is it something that's listed in the seed earlier than libmirclientplatform-android? | 18:11 |
| 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:12 |
| slangasek | (or at least, "above the thing whose dep order you need to override") | 18:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:20 |
| 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:21 |
| 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:23 |
| ogra_ | ah, right it was add_package() ... in live-build/auto/config | 18:24 |
| ogra_ | right, as i said, hacks :) | 18:24 |
| 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:32 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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 | 18:57 |
| cjwatson | doko: yeah, exactly what infinity said - I tried once or twice to port the delta over but it was a multi-hour job | 19:21 |
| bdmurray | slangasek: could you have a look at apport in the trusty -proposed queue? | 22:44 |
| slangasek | bdmurray: looking | 23:05 |
| bdmurray | thanks | 23:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!