=== chihchun_afk is now known as chihchun === ara_ is now known as ara [07:17] o/ [07:17] Is it only so hot at my place or is it a plague in all Europe? [07:34] sil2100, in my case it is actually cooler this week ;) [07:35] sil2100, I have created a vivid silo to sync with a wily silo because of this limitation for dual silo (as you cannot have CI packages+direct uploads for that kind of silos) [07:35] sil2100, but not working as you see ^^ [07:35] sil2100, any idea why this can be happening? [07:36] abeato: hey, let me take a look [07:37] sil2100, great [07:41] abeato: what packages would you like in this silo? [07:42] sil2100, ubuntu-touch-session synchronized from silo 57, pulseaudio that will need to be manually uploaded [07:43] sil2100, concretely from here https://launchpad.net/~canonical-arm-dev/+archive/ubuntu/ppa [07:43] ok, so I'll reconfigure the silo to be a sync from 57 and enable the pulsaudio source upload [07:43] sil2100, awesome, thanks [07:50] hey there [07:50] so first, it's not so hot here today (25 deg.) so it's not a plague like /everywhere/ in Europe [07:51] but close to it still, 34 tomorrow :/ [07:51] that's for sil2100 ;) [07:51] then, i'm still trying to get silo 31 cleared [07:52] dbarth: you want it completely gone and wiped away from the surface of earth? ;) [07:52] well, if i could merge it in trunk, it would be good [07:57] dbarth: let me take a look at it [07:57] dbarth: ah, it's waiting on QA sign-off, right? [07:58] I suppose QA should have more resources this week [08:00] sil2100, I need some help to upload pulseaudio to the silo, the people that could do that in my team is on holiday, who could help with that? [08:01] trainguards: hey guys. to mark a silo as tested now, do I just edit it to say "Ready for QA"? [08:02] just wanted to check before I nagged someone in QA :) [08:08] abeato: on it [08:08] pete-woods: yes :) [08:09] abeato: hm, I have no permission to open the PPA ;) [08:09] sil2100: thanks for the info :) [08:11] sil2100, I thought you had permissions for anything :) [08:12] sil2100: it's not; it's mostly building / packaging; smoke testing merely [08:13] sil2100: but it's a left over of an initial dual landing attempt [08:13] hence the qa required tag that may still be floating around that silo [08:14] at least, if qa wants to take it, it should be on the dashboard, but it's not; it's nowhere, so i'm trying to have it move "somewhere" at least ;) [08:18] dbarth: ah! I only noticed it now that it's wily [08:18] Ok, let me publish [08:18] abeato: apparently not ;) [08:19] dbarth: hm, when was the package built? [08:19] dbarth: was it built with gcc-5 already? [08:20] dbarth: I think we might need to rebuild it just in case [08:21] sil2100: it was before gcc5, so yes, i'll respin that one, and will do just as quick install on a wily phone to check that the program loads [08:21] dbarth: excellent :) Once you're done and happy with it, please switch the status to 'Publish without QA' [08:22] This means the silo has been tested and is ready for release [08:23] ok, deal ! [08:33] sil2100: hi! There is an error here (see line from queuebot ^) [08:34] sil2100: but I cannot find 0.17+15.04.20150410-0ubuntu2~gcc5.1 anywhere... where was it published? [08:34] sil2100: http://packages.ubuntu.com/search?keywords=signon-ui&searchon=names&suite=wily§ion=all doesn't have it [08:35] https://launchpad.net/ubuntu/+source/signon-ui/0.17+15.04.20150410-0ubuntu2~gcc5.1 [08:35] Laney: thanks, I'll sync that, then [08:45] Hi, I now have ubuntu-desktop rights, but can't access the CI stuff apparently since I am not a core-dev, is it possible to get this added? [08:58] mardy: hey! [08:58] sil2100: nw, it's solved now [08:58] mardy: we recommend using launchpad for checking published versions ;) The ~gcc5.1 version is in -proposed with all the other packages that are transitioning [08:59] (was in the landing meeting) [08:59] sil2100: yep, Laney pointed me at the right files [09:06] sil2100, jibel, image published, importer should pick it up now [09:06] hmm, unity8-dash was killed on my retail krillin by the OOM killer [09:06] and never came back [09:07] bah, can't file a bug against unity8 because it came from a ppa [09:07] thought we'd fixed that :( [09:16] ogra_: \o/ thanks! [09:24] * ogra_ sighs ... [09:26] cjwatson, someone abused the cdimage production branch as activity log (two pointelss direct commits about removing and re-adding a mairror entry), can i just revert that on nusakan or will that confuise the ~/cdimage/production branch even more ? [09:26] (I'm trying to add sil2100 to notify-addresses) [09:30] ah, just uncommitting them worked fine [09:43] sil2100, hmm so http://cdimage.ubuntu.com/ubuntu-touch/vivid/daily-preinstalled/20150810.1/ was published but i dont see the importer pick it up at all [09:43] ogra_: let me check that [09:43] in fact, despite the cdimage error the same image got published as 20150810/ too [09:44] aha [09:44] the MD5SUMS files didnt get updated [09:44] ugh, yeah, the imported dies in the middle [09:45] When generating the deltas [09:45] sil2100: ok, i need you for the publish button, i think, and then this should be all over (silo 031, no rush) [09:45] dbarth: on it! [09:45] sil2100, i'll try something, seems it fell over on the missing i386 build ... that will get us a .2 though [09:47] ogra_: better than not having anything ;) [09:47] dbarth: published :) [09:48] hmm, that doesnt seem to have produced anything :/ [10:02] The importer still crashes [10:02] ogra_: I see it dies when generating diffs in the ubuntu-touch/devel-proposed-g++5/ubuntu channel [10:02] So maybe that's related to some things slangasek was doing during the weekend? [10:21] sil2100, why would it do any diffs there for vivid, i think the two issues are rather unrelated [10:25] (cdimage not releasing the right thing vs system image not importing) [10:33] \o/ thanks sil2100 [10:41] sil2100, ok, i got the cdimage side of things fixed now ... [10:41] I'm looking at the importer still [10:41] sil2100, for the importer you shoudl perhaps just comment out wily for the moment [10:41] Looks like a tarball corruption... [10:42] there were no successful livefs builds for a while [10:46] Yeah, I'll switch it for manual for now and try to debug in the background [10:47] It looks to me as if one of the recent g++5 builds for wily simply generated a bollocks tarball [10:49] that can well be ... slangasek and infinity were experimenting with usin metapackages instead of tasks [10:50] though that shouldnt result in corrupted tarballs ... just with messed up content [10:54] ogra_: importer running anyway [10:54] Well, yeah [10:55] Messed up content can be the cause here as well as it fails during delta generation... but it failed really strangely almost as if when trying to get tarball content [10:59] * sil2100 starts getting spammed by cd image mails [10:59] :D [10:59] Hey, how can I get the powers to be able to land compiz/unity and all the rest of the deb-desktop stuff? [11:00] Trevinho: let me give you teh powerz [11:00] sil2100: thanks... seb128 will assist me on first landings [11:00] We give them out for free ;) [11:01] Trevinho: added to the right group, remember we have documentation for this: https://wiki.ubuntu.com/citrain/LandingProcess [11:04] sil2100: did you add darkxst? [11:07] sil2100: thanks [11:12] Laney: no, I can add him if needed [11:12] yes please, he's in the desktop team now [11:12] sil2100: or maybe make ubuntu-uploaders a train driving team? [11:15] I suppose we could do that, we already have the core-devs team as a member [11:15] ubuntu-uploaders is supposed to contain all people who have any upload rights [11:41] yay [11:41] * ogra_ got the update notification [11:42] 105 MB !!!! === chihchun is now known as chihchun_afk [11:44] sil2100, how can we have grown by 105 MB since friday ? [11:45] oh [11:45] new device tarball === _salem is now known as salem_ === alan_g is now known as alan_g|lunch [12:16] Ok guys, I need to go for lunch now and do some groceries shopping [12:16] Might be away for a bit longer, but will be around for longer as always [13:01] davmor2, finally got the qtmultimedia patch correct so vivid still boots, so just doing a quick sanity check of things and then I'll be ready to turn silo 38 over to you and your team [13:02] jhodapp: excellent how quickly do you want it broken? [13:02] davmor2, ha, as soon as I give the green light, as quickly as you can [13:03] jibel: ^ this is the silo that frees up indicators and scopes iirc === alan_g|lunch is now known as alan_g [13:20] pstolowski, tsdgeos: feel free to give silo 38 a try with the music-scope...background playlists should be working from it [13:20] jhodapp: cool [13:22] jhodapp, great, thanks! [13:23] np [13:24] tsdgeos, pstolowski: FYI, if you find bugs with it, file them against qtubuntu-media (ubuntu-rtm) and media-hub (ubuntu-rtm) [13:27] oki [13:32] jhodapp, can you do your testing and land the silo, or do you need us to verify? we need our another silo to land first before we're able to build our playback changes [13:33] pstolowski, no it's ok, I just wanted to let you know about the silo in case you were anxious to get testing your stuff right away [13:34] pstolowski, I expect bugs, this first release is merely to get the code landed making sure that it doesn't break any existing playback scenarios [13:34] jhodapp, that's ok, we should land asap due to FF, then we can fix remaining issues [13:34] sounds good! [13:36] davmor2, why is silo 19 set to "QA required" on bileto while you approved it earlier today? [13:38] jibel: meh my fault I forgot to mark it passed cause lunch got called [13:40] jibel: done now [13:40] davmor2, np, I thought it had been rebuilt or something [13:40] jibel: no but good job you noticed [15:00] sil2100, ogra_: the only change I made for tasks vs. metapackages was for the ubuntu desktop image; nothing that would have affected phone images or their importing. Is the importer still failing or did that get figured out? [15:02] slangasek: no, I'm looking into that now (was on lunch) - but I temporarily made the g++5 channel manual so that other channels can get imported [15:02] slangasek, i understood that sil2100 just ripped out the wily imports for now [15:05] ok [15:05] slangasek, arent you in heidleberg ? [15:05] * ogra_ kind of expected you in a EU TZ [15:07] ogra_: no, DebConf doesn't start until this coming weekend [15:07] well, debcamp :)) [15:07] * ogra_ ponders going this week, all the TLSP people seem to be there [15:07] *LTSP [15:09] sil2100, hello! could you please purge ppa 5 for me? [15:11] pstolowski: hey! Sure, clean completely? [15:11] sil2100, yes, i've some stale packages there [15:12] You want to re-assign it then? [15:12] Ok, cleaning [15:16] sil2100, ok, but i need a new one with same stuff [15:17] pstolowski: assigning [15:18] thanks [15:26] sil2100: is there a timeframe when you can land silo 48 in wily? [15:27] morphis: on it now! Sorry, was deep in debugging :) [15:27] Thanks for the poke [15:27] sil2100: np :) [15:28] just want to setup the sync silo to get it into vivid too [15:28] morphis: don't worry about the message ^ [15:28] ok [15:28] I'm running the watch_only build as that's required and publishing then [15:29] ok [15:40] davmor2, silo 38 ready to test in about 5 mins === tvoss is now known as tvoss|test === tvoss|test is now known as tvoss [15:51] robru, jibel, davmor2, ogra_: I don't suppose we have anything to discuss specifically on our evening meeting [15:52] Too hot to put a shirt on [15:52] davmor2, alright, silo 38 is ready for test (is there no way with bileto to mark a silo as ready for QA to test?) [15:52] jhodapp: yes [15:52] 'Ready for QA' in the sign-off field [15:52] sil2100, nothing from me. [15:52] sil2100, under edit? [15:53] jhodapp: yes [15:53] sil2100, unless I'm just missing it, I don't see that [15:53] sil2100, oh nm, same as QA Required [15:53] same list [15:55] sil2100, +1 for the shirt thing [16:06] hmmm, interesting [16:24] slangasek: ok, so I investigated a bit, and from what I see from daily-preinstalled-20150809 onward the custom tarball tarfile is hm... broken [16:25] slangasek: starting from that build onward, every custom tarball generated python tarfile dies when iterating through the files in the tarball and actually tar -xf also has some issues: [16:26] slangasek: http://paste.ubuntu.com/12049072/ [16:26] slangasek: the earlier tarballs do not have this error [16:26] slangasek: did you change anything that could be related when doing experiments over the weekend? [16:26] slangasek: the livecd build logs for good and bad builds seem to be almost identical [16:33] sil2100: nothing at all [16:35] slangasek: interesting thing is (might be a red herring though) is that both the broken builds have been done on kishi12 [16:35] Two good ones I saw so far were kishi11 and kishi13 [16:35] oh. is that the same one that I had a failed package build from over the weekend that made no sense? [16:36] Not sure, hm [16:36] no, that was kishi14 [16:36] sorry, all even numbers look alike to me [16:39] Anyway, really really strange [16:39] The two broken builds even have more 'Built files' in the LP view, the good ones only list the manifest - do you know if this means anything? [16:40] afraid I don't, sorry [16:40] infinity may be able to clarify [16:40] infinity: hey! Would appreciate your expertise in LP builders and such ;) [16:40] infinity: ^ [16:45] that builder thinks it's 1939? [16:46] Yeah, apparently [16:47] Although the build logs show a normal date [16:47] yeah [16:48] well, not quie [16:48] oh, doh [16:49] gotta remind myself to ignore the kernel date [16:49] slangasek: can I kick an image for testing? [16:49] Maybe I'll get a new builder, and the same way I'll check if it's not anything funny and transient [16:53] hmmmmm [16:55] The interesting thing is that all the good builds had only the manifest in the Built Files, even when accessing it through LP API I can't get the resulting tarballs, although cdimage seems to find them somehow through the librarian - anyway, I'll kick off a new image [17:01] sil2100: I'll look in a second. [17:02] infinity: thanks - let me paste you the links to the builds here (the ones with 'good customs' and bad ones) [17:02] infinity: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-touch/+build/34535 <- a good one, for instance [17:03] infinity: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-touch/+build/34639 <- a bad one (with lots of files in it, and it actually makes sense that the builder lists those) === alan_g is now known as alan_g|EOD [17:15] sil2100: I think you might have your good and bad reversed... [17:15] sil2100: The one with all the files is clearly "good", no? [17:15] infinity: well, from the LP POV, yes, but those with all the files actually have broken custom tarballs generated [17:15] sil2100: The one missing all the boot images is "bad", but it's a product of how ogra wrote this bit of livecd-rootfs that it ignores failures on copying those. [17:15] (with invalid timestamps in some files) [17:16] Oh [17:16] sil2100: If they're broken, that's not LP's fault. :P [17:16] infinity, i was asked to do that [17:16] infinity: so does it mean that when there are no files listed, it means it uses some old versions of the files it failed to copy? [17:16] ogra_: I'm not saying it's only your "fault", per se, but ignoring failure is always dangerous. [17:16] so that the missing zip doesnt make the build fail since we had a transition period wheer you could install phones from android zips [17:16] Since I see the cd-image build logs still mention that it's fetching all those files from the librarian, but I'm not sure where it's taking those from [17:17] nowadays we dont produce zips at all so that code could as well get wiped [17:17] it just produces log noise [17:17] ogra_: zips? Y [17:18] ogra_: Sorry, I'm ignorant of the touch build process. Do you mean all the .img stuff is irelevant to the final product? [17:18] infinity, we started with android zips when doing the phone images [17:18] no, the img stuff is relevant [17:18] ogra_: Okay, the img stuff is what I'm talking about. [17:18] ogra_: When they fail to exist, you ignore errors on copying them. [17:18] the zip stuff that is explicitly || true'ed isnt [17:19] hmm, for the actual phone imgs ? [17:19] ogra_: See https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-touch/+build/34535 which has no .img files, cause they all didn't copy. [17:19] * ogra_ checks the code [17:19] infinity: maybe you could help me out in understanding something: http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-touch/wily/daily-preinstalled-20150808.log <- this mentions fetching all the files like the custom tarball, rootfs etc. but the build in LP doesn't list those at all [17:19] Actually, it has no livefs either. This is kinda special. Why did this "succeed"? [17:19] infinity: do you know where it takes those from in that case, since you said it actually failed copying them? [17:19] (it's this one: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-touch/+build/34535 ) [17:20] 77 # Android 4.4.2 based images do not ship a .zip file, do not fail if it does not exist [17:20] 478 cp -v chroot/usr/share/android/product/*-preinstalled-touch-armel+${subarch}.zip\ [17:20] 479 "${PREFIX}.armel+${subarch}.zip" || true [17:20] ogra_: Oh, no. Some of them did copy, I'm misreading the log. They didn't get returned to LP. Or something. [17:20] thats the only place where i skip copying [17:20] ogra_: Yeah, sorry for maligning you, I was misreading the log. [17:20] live-build/auto/build ... at the bottom [17:20] but these three lines should really get wiped [17:21] sil2100: This is an LP display issue, perhaps. If the files are in the librarian and being fetched, it's bizarre that they're not on the page. [17:21] we will never again produce zips [17:21] cjwatson: Halp. [17:23] sil2100: Individual builders have no control over what shows up in the UI, except for building the bits in the first place. THey must be being built and returned, or there'd be nothing to fetch from the librarian, so the UI here is confusing, to say the least. [17:24] infinity: ok, I tried fetching them from lp-shell but .getFileUrls() also returns just the manifest, which is strange! [17:24] Probably unrelated to our tarball issues tho [17:24] Still, it confused me a bit [17:24] infinity: anyway, thanks for the explaination [17:25] I suppose the CD build could be failing to find files and reverting to an old build, but I'd think it would log when it does that. [17:26] hmm, that could explain some of our problems, I wonder if that's the cae [17:26] cdimage doesnt use LP at all [17:26] *case [17:26] pfff [17:26] it only looks at nusakans local FS [17:26] (unless i misremember) [17:26] ogra_: Well, the bit that builds and pulls livefses looks at LP. :P [17:26] yeah, that does [17:26] ogra_: And the build log clearly shows it downloading from the librarian. [17:26] Anyway, I'll get back to this tomorrow, now I need to go and cool myself up or I'll go crazy [17:26] but the final publishing doesnt, does it ? [17:27] oh, then i remember wrong [17:27] ogra_: This isn't about the final publish, but where the files came from before then. [17:27] ah [17:28] sil2100: Anyhow, the newer build seems to be correct, right? (as in, building the right bits, not necessarily building them correctly, but that wouldn't be an LP issue) [17:28] sil2100: What's the actual complaint about the new bits? [17:29] infinity: the new build looks ok, so no complaint besides the issues that we're seeing, probably caused by something strange somewhere else [17:30] did xz change in incompatible ways in wily ? [17:30] The issues being the custom tarball having files timestamped at 1939-06-11 07:15:28 [17:30] sil2100: Oh, I thought you said the new ones were weirdly broken. [17:30] so that you cant properly diff the tarballs anymore ? [17:30] Well, only the new custom tarball is weirdly broken [17:30] Which causes the system-image importer to die when trying to import those [17:30] well, that doesnt involve LP or cdimage or live-build at all [17:31] the custom tarballs come from some jenkins build afaik [17:31] ogra_: no, not the /ubuntu ones [17:31] We create those at run time with livecd-rootfs [17:31] ah [17:31] I mean, cdimage-custom creates those [17:32] yeah, i remember that, that was slangasek's work iirc [17:32] sil2100: Which file(s)? [17:32] 317 (cd "binary/$INITFS/custom.dir/" && tar -c *) | \ [17:32] 318 gzip -9 --rsyncable > "$PREFIX.custom.tar.gz" [17:32] 319 chmod 644 "$PREFIX.custom.tar.gz" [17:32] Oh, I see them. [17:32] -rw------- 1 root root 4249 Jun 10 1939 click_com.ubuntu.filemanager_filemanager_0.4.386 [17:32] infinity: http://paste.ubuntu.com/12049072/ <- click apparmor profiles [17:33] Etc. [17:33] Are those created at build time, or copied from a package? [17:33] (from livecd-rootfs) [17:33] hmm [17:34] infinity: created at build time by a livecd-rootfs hook IIRC [17:34] Okay, it's just the ones in the cache, so I assume that's build-time. [17:34] But buildds ntpdate at runtime. [17:34] 10 Aug 02:04:20 ntpdate[23960]: adjust time server 10.211.37.1 offset 0.000787 sec [17:34] infinity, live-build/ubuntu-touch/hooks/60-install-click.chroot [17:35] Which went correctly for that build. [17:35] Right, all seemed fine with the date on the builder apparently [17:35] that script wgets the clicks from http://archive-team.internal/click_packages [17:36] So, click/apparmor bug? [17:36] nd then runs "click install" n them [17:37] Should be able to test that in a chroot. It's not doing anything terribly complex. [17:37] that message is fine in teh log "WARN: AppArmor not available when processing AppArmor hook" [17:37] (expected) [17:38] No recent apparmor or click upload to wily [17:38] Or anywhere else [17:39] Ok, I need to disconnect now, thanks for looking into this o/ I'll get back to this tomorrow if anything [17:39] well, and the log looks fine on both, broken and good builds [17:39] Do old/good builds have that vala complaint about connecting to logind? [17:39] yes [17:40] even the duplicated apparmor message in the later few clicks [17:40] that part of the log looks exactly the same [17:45] * ogra_ notes that the app store was recently upgraded ... i wonder if that possibly influenced the timestamps of the clicks [17:52] infinity, i bet itis the nnew store that was just rolled out [17:52] since we pull the clicks from there [17:55] oh, no, wait [17:55] thats only the apparmor profiles [17:55] live-build/ubuntu-touch/hooks/90-precompile-apparmor-policies.chroot generates them [17:56] cho "I: precompiling custom click apparmor policies" [17:56] mkdir -p /custom/cache/apparmor [17:56] /sbin/apparmor_parser -M ${FEATURES} -Q --write-cache --cache-loc=/custom/cache/apparmor/ `find /var/lib/apparmor/profiles/ -maxdepth 1 -type f -not -path '*/\.*'` [17:56] i wonder if there is a -v switch to apparmor_parser ;) [17:57] hmm, no, only --debug ... and that doesnt sound like it would only be verbose [17:57] bah, i'm blind, there iis --verbose [17:58] i would suggest we add that be default to these lines ... so we get more output (even if that doesnt fix anything it should make it easier) [18:02] Mirv: you still around? I need some gl/gles advice. === tvoss is now known as tvoss|test === tvoss|test is now known as tvoss === tvoss is now known as tvoss|test === tvoss|test is now known as tvoss [18:20] oSoMoN: silo 005 is still in needs review state can you get it approved please [18:20] davmor2, oh, right, let me do that now [18:21] done === cwayne-afk is now known as cwayne [18:30] trainguards: does anyone have some time to publish silo 56? it's holding up one of my silos [18:30] pete-woods: oh sure. I assumed kenvandine would do it, but I'm here [18:31] robru: that would be great :) [18:32] woot! packages migrating [18:33] oSoMoN: thanks [18:34] robru, pete-woods: thx, i hadn't noticed it was ready to publish :) [18:34] kenvandine: pete-woods you're welcome [20:42] popey: if you get a chance need a review of new gallery-app [20:42] in store [21:44] veebers: hah, for real this time? [21:44] robru: heh, it was for realz last time too but got changed back :-P [21:45] veebers: you didn't ask me to publish it when we discussed it though [21:45] veebers: anyway do you want me to publish it now? [21:49] robru: ah right, due to the confusion and another comment I wanted to double check the testing. Yes please :-) [21:49] ok [21:50] robru: awesome, thanks [21:51] veebers: you're welcome === salem_ is now known as _salem