=== 5EXABD84D is now known as infinity === chihchun_afk is now known as chihchun [07:28] Mirv: uh oh qt 5.4.2! [07:28] Mirv: oh, and you assigned line 51? [07:29] sil2100: well I thought it might be a good idea for wily, before GCC5 and Qt 5.5 and all that uncertain crazinesss... [07:29] Ah! [07:29] sil2100: yes, I assigned [07:29] Ok, good that you assigned, I mis-read the comment actually [07:29] sil2100: I mean, there are so many uncertainty factors in my mind regarding wily that I'm not 100% sure we will ship 5.5... but if we get once again bugs fixed, it can be done. [07:30] Since this sync is indeed needed *before* silo 4, because they couldn't dual land it due to address-book-app differences [07:30] I won't eg ship without the qml cache patch and that's unfortunately in limbo since people have so many other priorities [07:30] Ah, right, ricmm is working on different things now [07:30] * Mirv has shiny XPS 13 in use, migrated during weekend! [07:30] \o/ [07:30] sil2100: yes :( it was supposed to be both adapted for 5.5 and submitted upstream, now... [07:31] sil2100: \o/ indeed. working screen! fast! fast fast! [07:31] like 3 generations newer fast. [07:31] Let's have a chat with ricmm later on, maybe we can somehow convince management to get this done [07:31] even though nowadays it's not that huge as it sounds regarding CPU speed. [07:31] hoo [07:31] Nice! [07:32] * sil2100 sticks with his old laptop for now [07:32] sil2100: I fired one e-mail at pat + ricardo as ricmm suggested but as I didn't get a reply (from pat) I assume it's not a priority [07:32] but we can try... [07:32] I have certain requirements for laptop hardware and currently there's nothing that could interest me [07:34] finally the dashboard and spreadsheet do not annoy me anymore too :) because they're no longer as laggy. [07:35] but they're both quite overheavy pieces [07:35] requiring the latest 2015 machine to work fluently [07:35] oh, I read _wily_, not wily vivid [07:36] sil2100: how's the status with landing gates... [07:36] argh, I need to revert that anyway since the QA field was empty [07:36] train should really just abort on such case [07:37] that's luckily easy as there was no earlier mediascanner2 in the overlay PPA [07:39] robru: sil2100: could we perhaps switch to "dual" string in the dashboard instead of "wily vivid"? I've found myself also earlier parsing that as "oh, wily" and dual would make it explicitly "not just wily" [07:41] Mirv: hm, that might be an option [07:42] Mirv: the landing gates are closed *but* we wanted to open them today anyway [07:42] So probably no harm ndone ;) [07:42] Mirv: do not remove it from the PPA yet [07:42] sil2100: yes there is, as noted above it was not QA sign-off:d [07:42] Ah, ok [07:42] Ouch [07:43] but this is pretty easy one, I deleted it from the PPA, there was no earlier version in the PPA, wily got released. if QA signs off, just publish the vivid one again. [07:43] (or copy-package if train doesn't like the fact that wily already has it) [07:49] It might be a bit troublesome since PPAs don't like to re-copy the same package version [07:49] Not sure how long this info stays in the PPA after a deletion [07:49] Anyway, we can do a manual version bump if anyuthing [07:55] sil2100: ah, darn, that's a problem indeed. it is possible to copy just-deleted same package back to the same PPA, restoring it, but I'm not sure if I've ever tried copying from another PPA later on. [07:56] sil2100, Hey, we'd need a new image with latest mir that landed on Friday [07:56] sil2100: it's safe to say the info stays there indefinitely [07:57] Mirv: as said, we can just take the package, change the version to ubuntu2 and push it manually in the worst case :) [07:57] jibel: ok, let me kick a new build the [07:57] *then [07:58] jibel: it's building [08:00] sil2100, we'll probalbly need another to update translations [08:00] Right, but I think translations are auto-uploaded on Tuesdays... maybe we could ask pitti to run the update job earlier though [08:01] He's doing the german translations now [08:01] sil2100, once the missing translations are completed, which is what seb128 and pitti are doing [08:03] jibel, we need to find a spanish translators to validate the translations from vrruiz [08:04] https://translations.launchpad.net/dialer-app/trunk/+pots/dialer-app/es/+translate?show=untranslated [08:04] same on messaging as well [08:05] or seems like messaging got done [08:05] seb128, ok, i'll see with victor if he knows someone. [08:06] otherwise it'll be leo or sergio this afternoon === davmor2_hols is now known as davmor2 === tvoss is now known as tvoss|test === tvoss|test is now known as tvoss === mandel|lunch is now known as mandel [08:32] ogra_: pong [08:32] ping ? [08:32] oh [08:32] no harps !!! [08:59] jibel: we have 1.5h for verifying the spanish translations ;p [08:59] sil2100, I know :) [08:59] sil2100, I found someone for the verification but need someone to actually approve them [09:02] dpm can do that I guess [09:03] dpm, ping [09:05] seb128, jibel, what's the context? [09:06] dpm, we need someone to approve https://translations.launchpad.net/dialer-app/trunk/+pots/dialer-app/es/+translate?show=untranslated [09:07] dpm, can you decide which translation is correct for the 1st sentence, fgimenez and victor have different suggestions [09:07] dpm, the 3 others are ook [09:07] -o [09:08] "Listo" is what got used in the messaging-app, if you change it in dialer you probably want to change messaging as well for consistency [09:08] https://translations.launchpad.net/messaging-app/trunk/+pots/messaging-app/es/32/+translate [09:08] jibel, I'm not a member of the Spanish translation team, but FWIW, Victor's suggestions are the correct ones [09:10] dpm, ah, maybe you should apply :) Unless you know a member we'll have to wait for victor then [09:10] dpm, thanks [09:11] jibel, moving forward, I think to avoid this, the best thing would be to send an e-mail to the translators mailing list [09:11] dpm, you should be able to approve them anyway no? [09:12] not sure I can commit to do translations for yet another theam [09:12] seb128, I can approve them as a Launchpad admin, but not as a team member, not sure I want to bypass the team mechanisms [09:15] dpm, k, I'm pondering doing it :p I don't know spanish but it's basically approving the translations that got used in the dialer-app trunk [09:15] it doesn't feel like approving new work [09:15] just copying over things done [09:23] dpm: can you contact the spanish translator team admins somehow to get these translations approved? We need them ASAP since otherwise we'll miss the export and will have to ask for a manual one ;) [09:23] And we cannot release OTA-4 with missing key translations [09:25] sil2100, in the future, could we send an e-mail to ubuntu-translators to avoid this situation? I've just come back from vacation, so apologies if that's already been done and I haven't seen it yet [09:25] dpm: Can you approve them? There is no one in #ubuntu-l10n-es, and I usually ping elopio por urgent translations. [09:26] But elopio lives in Costa Rica, will be late if we wait for him [09:26] dpm, there is this proposal, which you commented on, to have a string freeze and that includes emailing translators [09:26] sil2100, seb128, dpm, sounds like a good topic to start a snappy discussion about ... "handle translations in snaps" ... once the system-image setup for images got replaced by snaps we could probably unbundle translations from the core image [09:27] ogra_, yeah, I guess we could do that [09:28] rvr, I'll approve them as a one off to unblock this situation, but I'd rather not do this in the future and bypass the team. As an aside, I myself would translate "Got it" as "De acuerdo" instead of "Listo", but I'm not familiar with the guidelines [09:29] dpm: I agree with you, I can suggest that translation [09:29] and please, even if the string freeze policy is not yet in place, an e-mail to ubuntu-translators does not take more than 2 mins to send. The Spanish team are responsive enough and generally get translations done in a matter of hours [09:29] dpm: Done [09:30] translations approved [09:30] dpm: Thanks [09:35] dpm, rvr, you probably want to change https://translations.launchpad.net/messaging-app/trunk/+pots/messaging-app/es/32/+translate as well then, for consistency [09:35] seb128: dpm: Done [09:37] seb128: dpm: Needs approval, though [09:39] rvr, I'd rather the Spanish team does this, as it's a discussion about nomenclature and it's not blocking any release [09:54] jibel, rvr: so do we now have all the required translations in place? [09:54] * ogra_ wonders what happened to the image [09:55] Which one? [09:55] the one from 10:00 [09:55] https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-touch/+build/29104 [09:55] ogra_: it seems to have built, not sure if the importer finished it up already [09:56] well, the rootfs finished 1h ago [09:56] Yeah, the importer is still running since 30 minutes [09:56] ah, k [09:56] At least [09:56] slow thing :P [09:56] Damn, this is getting really slow due to all the additions lately ;p [09:56] yep [09:57] more devices ... more imports [09:57] by end of the year it will run 2h :P [09:57] I think the 'building images doesn't cost us much' statement is less and less accurate as we're losing time ;) [09:58] sil2100: No untranslated items in messaging app and dialer app (trunk) [09:58] sil2100: So I think it's ready [10:00] there it is ! [11:47] * sil2100 prepares lunch === chihchun is now known as chihchun_afk [12:11] jibel: kicking the new image [12:11] As per changes e-mail, langpacks have been uploaded [12:14] sil2100, ok === _salem is now known as salem_ [13:11] trainguards so are we thawed on vivid+ ? [13:11] kgunn: hey! What do you mean? [13:11] * Mirv searches dictionary :D [13:11] meaing can stuff land in vivid+ now? [13:12] thaw!=frozen [13:12] non-freeze, ah [13:12] We're opening the landing gates basically in a minute, just finished lunch - we had to re-roll an image with the new mir and translations [13:12] \o/ [13:12] kgunn: but QA already looked into your silos not to waste time :) [13:12] Not sure if they were able to validate silo 8 or not, but that was the plan [13:12] So that once we're open, stuff can land [13:12] oh man...dreams do come true [13:13] We'll still have to rebuild silo 4 then ;/ [13:13] jibel: do you know if you guys checked out silo 8 already? [13:14] jibel: I think now that the rootfs is basically done, well, I suppose we could open the gates, right? Any objections? [13:14] sil2100, is it ready for QA? [13:14] if it is then someone mark it so and we'll start [13:14] Uh, no, not sure if there was anyone around to take care of it, I thought you guys wanted to start once it built anyway [13:16] Nevermind then [13:16] Let me open the gates [14:01] * sil2100 sighs [14:01] So much rewriting [14:01] mzanetti: ping! Could you test silo 8 and mark it as ready for testing? [14:18] rvr, image 27 is out, can you confirm that translations are fine? [14:20] If it's fine, I'll copy it to the RC channel [14:21] Will wait for your confirmation [14:36] jibel: Flashing [15:03] davmor2, you moved silo 45 to testing passed but didn't mark the spreadsheet, intentional? [15:09] sil2100: jibel: Wizard appear in English [15:09] ? [15:09] sil2100: jibel: In /usr/share/locale-langpack/es/LC_MESSAGES/messaging-app.mo I don't see any "Got it" or "Swipe to reveal actions" [15:11] language-pack-touch-es 1:15.04+20150608 [15:11] Something went wrong then [15:12] My knowledge of translations is a bit too small... we'll probably have to poke pitti about those [15:14] sil2100, pmcgowan: need a silo for line 54 to fix https://bugs.launchpad.net/barajas/+bug/1462416 [15:14] Error: launchpad bug 1462416 not found [15:14] sil2100: Talking to him [15:14] bfiller: looking [15:19] sil2100, rvr, why is that discussion with pitti not happening there or a channel where others can participate? [15:19] sil2100, rvr, anyway, you are probably going to come to the same conclusion but the issue is [15:19] https://launchpadlibrarian.net/208568312/language-pack-touch-es_1%3A15.04%2B20150601_1%3A15.04%2B20150608.diff.gz [15:19] seb128: I didn't find pitti here [15:19] +"X-Launchpad-Export-Date: 2015-06-08 11:12+0000\n" [15:19] hum [15:19] oh, +0 [15:19] that was after you approved the translations? [15:20] rvr, I guess those langpacks are built from the vivid translations set [15:20] e.g https://translations.launchpad.net/ubuntu/vivid/+source/dialer-app [15:20] seb128: Yes [15:20] not from wily/trunk [15:20] http://people.canonical.com/~ogra/touch-image-stats/vivid/20150608.1.changes [15:21] well, vivid doesn't have those strings [15:21] FYI [15:21] Hi pitti [15:21] ogra_, yeah, it's just that the langpacks come from vivid serie [15:21] hello [15:21] (thats the most recent image) [15:21] I think [15:21] <seb128> rvr, I guess those langpacks are built from the vivid translations set [15:21] pitti: ^ [15:21] :) [15:21] and the new strings are in trunk/wily only [15:21] ah [15:21] ah, I just pinged about that in #ubuntu-touch [15:21] wily ... the source of all evil :P [15:22] pitti, ah, -touch works for me as well [15:22] pitti | sil2100: our overlay PPA doesn't have any support for translations/message sharing [15:22] or here [15:22] pitti | as it's neither vivid nor wily [15:22] pitti | so while e. g. trunk has a new message "Got it": https://translations.launchpad.net/dialer-app/trunk/+pots/dialer-app/es/+translate?search=Got [15:22] pitti | the same message isn't in https://translations.launchpad.net/ubuntu/vivid/+source/dialer-app/+pots/dialer-app/es/+translate?search=Got [15:22] Launchpad translations only supports distros, not PPAs [15:22] so while we had translation support for RTM, we don't for a "random PPA" [15:23] pitti, any idea how to workaround that? [15:23] yeah, RTM was a distro [15:23] not really [15:23] pmcgowan, ^ more fun [15:23] we can crowbar the wily translations into the overlay [15:23] but that would break again if wily has packages/versions which aren't in the overlay PPA [15:23] well, that's assuming that wily and vivid+overlay branches don't diverge [15:23] which you can't assume [15:23] exactly [15:23] the overlay PPA is neither wily nor vivid [15:24] ogra_, see, that's for that sort of reason that I think that we should keep wily and vivid+overlay sources in sync [15:24] pitti, it is amphibian ;) [15:25] seb128, yeah, i thought thats what the double landing does [15:25] ogra_, well, double landing is an option, not an enforced rules [15:25] so nothing block $randomcomponent to diverge [15:25] make it a rule then ? [15:25] I think this wasn't considered during the decision-making [15:25] not sure that works either [15:26] ogra_: well, that wouldn't work, as wily can have different strings as it can have development features [15:26] So even though we enforce anything that's in vivid-overlay to be in wily, we can't do the same other way around... [15:26] yeah, feared that [15:27] sil2100, pitti so how do we update the translation in the PPA? [15:27] pitti: we'll probably have to poke the launchpad team about that [15:27] They would know if they can make a quick workaround for us [15:27] seb128: erk, it's not enforced? [15:27] Since the milk has been spilled, not much we can do - but I'm feeling more and more that the PPA idea wasn't so nice in the end [15:27] we fell into that trap once already [15:28] pitti: it's enforced only in one direction, not the other [15:28] not sure that there's a quick workaround -- the PPA doesn't build translation tarballs, they don't get imported anywhere, so we don't have correct PO templates for the PPA anywher [15:28] e [15:28] pitti: since the reason we have the overlay and wily is that wily can be for development, non-stable work as well [15:29] sil2100, does this mean we have not gotten translations since making the PPA? I am confused [15:29] pmcgowan, we only got vivid translations [15:29] pmcgowan: correct [15:29] pmcgowan, which didnt actually change since release [15:29] pmcgowan: it seems we didn't get any updated ones, but only now it seems to have been made visible [15:29] well, we did get updates [15:30] but only for strings that are already in vivid [15:30] Right [15:30] which hid the fact that there weren't new strings [15:30] I see [15:30] dang [15:31] Things are getting better and better [15:31] sil2100, pitti can we for now just get the wily version and push it in? [15:31] the proper solution is obviously PPA support in the langpack importer ... [15:31] but that might take quite some effort [15:31] or moving the PPA into RTM/15.04 or something such [15:31] pitti: ^ ? What do you think? The strings in wily and overlay should be the same right now [15:32] sil2100, are you sure ? [15:32] sil2100: didn't you say that wily could have newer versions than the overlay? [15:32] if these dropped any string, we lose those [15:32] pitti: it *can*, but not sure if it does [15:32] yeah, i'd be careful with such claims [15:32] (or "changed", which is the same basically) [15:32] pitti: I'm just saying it would be better than what we have right now anyway [15:32] and we know how often we did pointless changes in strings :) [15:32] so, the crux is, we don't have *.pot files for the overlay [15:33] pmcgowan, sil2100, pitti, I would be careful to use the wily one, for what we know some strings might just have been modified and the vivid-overlay version droped from wily that would regress the vivid users translations [15:33] if we do, the packs can be pieced together (in principle) from the vivid and wily translations, assuming that everything that's in the PPA is in either vivid or wily [15:33] if the PPA has a newer version than in wily, we lose [15:34] slangasek: ping [15:34] pitti: I'm starting to consider the idea of using an ubuntu-rtm series instead of the overlay [15:34] sil2100: oh -- we actually did generate translation tarballs, e. g. in https://launchpadlibrarian.net/205869413/buildlog_ubuntu-vivid-amd64.dialer-app_0.1%2B15.04.20150507.1-0ubuntu1_BUILDING.txt.gz [15:35] but they didn't get imported anywhere [15:35] so we'd need to iterate over all builds, find the _translations.tar in the librarian, download all of them, download vivid+wily+trunk translations, and do a big msgmerge over them [15:36] i. e. the whole thing that LP usually does [15:36] pitti: since we already got bit many times by some of the PPA short-comings which we had to work-around, like bug-autoclosing, lack of proposed migration, lack of changes-emails [15:36] sil2100: yeah, TBH I was quite surprised that we moved back to a PPA once we spent months making ubuntu-rtm actually work [15:36] I'd like slangasek joining this discussion, maybe he'll have some ideas [15:36] is ubuntu-rtm worse than a PPA? [15:37] sil2100, the rtm distro seemed to work fine to me, why did we decide on a ppa instead? [15:37] it's certainly a lot more duplication as ubuntu-rtm has to be a complete distro [15:37] as opposed to just an overlay [15:37] that might have been a key reason [15:37] well, that was a bootstrap issue [15:37] copy enough to get it to work [15:37] then it was similar to the overlay [15:37] just upload what is needed [15:37] seb128: I wasn't on the final meeting where the decision has been made, I guess one of the arguments was that with the overlay PPA we're actually basing on top of a released series and can get updates/security from them [15:38] we avoided the distro in order to make use of security and udates [15:38] sil2100, yeah that [15:38] we could easily auto pocket those to another distro no? [15:38] It's a solid reason to be fair, but I don't think it's important enough to cope with so many issues [15:38] pitti, ubuntu-rtm means a super limited archive [15:39] having a cron copy would be less work that all the workaround you have for -changes/translations/etc [15:39] I proposed making a script that would report every change happening in vivid-updates and propose a sync [15:39] ogra_: sure, just the expansion of build/binary deps of ubuntu-touch, so it's muuuch smaller [15:39] pitti, it isnt a whole archive mirror, only the seed subset [15:39] ogra_: I was just trying to come up with reasons why rtm is worse than PPA [15:39] well, this is one :) [15:39] Yeah, but I think we shouldn't put LP resources as a priority here [15:40] right, duplication and re-using of -security/-updates [15:40] the other is SRUs and security [15:40] but the latter can just be copied [15:40] I think conceptually an entire new distro is too much (requires too much duplication of packages, cron jobs, building, testing, etc.) [15:40] and a PPA is too little (no translation/bug closing/bug tracking. etc.) [15:41] one big advantage of RTM is that publisher runs only take a fraction of the time they take with the full archive [15:41] conceptually the right thign would be a distro release [15:41] so the turnaround time for a package is significantly fster [15:41] but that doesn't work well with wily and vivid+touch being open in parallel [15:41] ogra_: that's the same for a PPA, though? [15:42] not sure [15:42] * ogra_ moved to snappy before having to wait for PPA packages to land on the phone :) [15:42] trainguards: hey ho, can I have a silo for line 55 please? [15:42] anyway, coming back to the translation thing: it seems we have most of the data (except for things where the overlay went ahead of wily), but implementing all this piecing together sounds like two days work or so [15:43] Yeah [15:43] oSoMoN: on it in a minute [15:43] packages in overlay which are newer than in wily need to be landed in wily, so that we get their translations *somewhere* in ubuntu [15:43] pitti, ogra_: in Austin I got convinced to the PPA idea, but now I'm not convinced anymore [15:44] Since it feels like we're just duct-taping more and more things [15:44] The worst thing is that for now, like this instant, we don't have a solution that we could just use [15:44] a little late now though :) [15:45] sil2100: couldn't we open rtm/15.04, copy the touch parts of vivid into it, and then copy the PPA contents into it? [15:45] Switching to ubuntu-rtm does require rather a lot of work from both the landing team, LP team and archive admins [15:45] ah, ok [15:46] pitti: we could, but then it would mean we need to modify the CI Train again to not use the overlay, there's also some fun with versioning that we'd have to implement etc. [15:46] The archive parts seem the easiest ;p [15:46] do we have auto-committing of LP translations into trunks? [15:46] i. e. does everythign that gets translated in LP get into lp:project? [15:47] It was working fine in the past, so I think yes [15:47] if so, then another option (not necessarily the best, but for completeness) would be to rebuild all ppa packages without pkgbinarymangler [15:47] we'd lose the possibility to update translations through langpacks, but it seems we didn't have that for new strings in the first place [15:48] (technically: upload pkgbinarymangler to the PPA which disables pkgstriptranslations and do no-change rebuilds) [15:48] uhh, hm [15:48] Personally I would prefer to avoid that ;) [15:49] so the process for updating a translation would then be to do that in LP, and land the project [15:49] (no cron or automated updats) [15:49] sil2100: yeah, I was just bringing it up to get all options on the table [15:49] pitti: I guess we could do that as a last resort, but I would rather prefer doing all the troublesome work and migrate to ubuntu-rtm instead ;p [15:51] sil2100, pitti, if the only issue for that ota is those 4 new strings in messaging/dialer, we can probably manually patch the langpacks in the overlay ppa for the languages we care about as a workaround [15:52] not a solution, but to unblock the ota update [15:52] seb128: rtm had some pretty serious lurking problems, notably some terrible issues with version conflicts with Ubuntu [15:52] seb128: ... and disable the auto-update cronjob [15:53] seb128: hm, ok, that makes sense, I don't know enough about translations to have considered that as an option, but if that could be done then great [15:53] but the translations problem is an issue too, and hard to fix with a PPA; I admit I don't think we considered this [15:53] Since a short-term solution is what we need right now [15:53] The long-term one will have to be discussed and decided [15:53] sigh [15:53] hm, given how liberal we've been with string changes in the past, did we really only add these 4? [15:54] my krillin is not happy at all with the last image [15:54] (in the overlay PPA) [15:54] apparmor kicks in ... not sure why [15:54] (given only langpacks changed) [15:54] pitti: those were at least the only ones that QA saw, but I'm pretty sure they don't test all core apps for translations... [15:54] ogra_: uh [15:54] ogra_: What do you mean? [15:54] ah, but not the full 15min [15:55] can this wait until we get a chance to talk about it in the next LP team meeting tomorrow? [15:55] rvr, the boot after upgrade took long [15:55] ogra_: Ah, ok [15:55] cjwatson: I'm pretty sure it can, we can't decide on something that big in just an hour anyway :) [15:55] rvr, usually that means apparmor rules get upgraded ... my switch from RTM to OTA4 on the weekend got me a 25min boot [15:55] I mean, at least the long-term solution [15:56] Since we'd probably like to fix the translations short-term as soon as possible [15:56] pitti: could you anyway disable the auto-updater cronjob for overlay? I guess it won't be needed for now [15:56] Bringing up ubuntu-rtm/15.04 can't really be a very short-term thing [15:56] rvr, and there is not much we can do ... on this upgrade people will have to get their apparmor rules for all apps they installed themselves regenerated ... [15:56] rvr, that will cause really long boots after the upgrade [15:57] sil2100: as you wish; note that it still updates untranslated strings which were already in vivid [15:57] pmcgowan, ^^^ we need to mention that in the release announcement for OTA4 [15:57] cjwatson: no no, I don't consider ubuntu-rtm/15.04 as the short-term solution, that's like the long-term one [15:57] sil2100: but if you want to go with the "hand-patch these four strings" route for now, we should disable it indeed [15:57] sil2100: just confirming that this is what you want [15:57] sil2100: phew [15:57] pmcgowan, if you installed 100 apps from the store the first boot after upgrade will take quite a while [15:57] when going to OTA4 [15:57] pitti: yeah... that's what I think of right now - we already fetched the latest vivid strings today anyway [15:58] ogra_: just like Android updates then :) [15:58] cjwatson, well, no UI feedback [15:58] ah well yes [15:58] but yeah, beyond that pretty similar :) [15:58] sil2100: disabled [15:58] pitti: thanks [15:58] ogra_, is that due to apparmor running? [15:58] pmcgowan, yes [15:58] sil2100, pitti: I can handle the patching, but that's probably going to be for tomorrow now [15:59] need to go in less than an hour and still working on something [15:59] yeah, same here :/ [15:59] but then again, this is not rocket science -- get the source package, patch the .po files, reupload [15:59] pmcgowan, we can only pre-generate for preinstalled packages ... due to the fact that there is a new kernel *and* new apparmor all manually installed clicks will have to re-generate [15:59] seb128: ok, no worries, thanks - I'll check on it briefly myself but I suppose tomorrow sounds fine [15:59] Indeed [15:59] pmcgowan, if you have really many clicks installed that takes quite a while [16:00] I suppose patching the most important languages makes the most sense in this case [16:00] sil2100, right, pmcgowan gave a list on the bug, but I would do at least es/de/fr [16:00] I wonder if we have good chinese translations as well [16:01] is the bq sold at all in china? [16:01] chinese less imortant for now, will be soon though [16:01] right [16:01] it is sold there but as a developer thing [16:01] so english supposed to be ok [16:01] right, and it's only a few strings in a tutorial [16:02] devs should be able to get over it === tvoss is now known as tvoss|dinner [16:05] sil2100: need a reconfigure on silo 8 please, removed one package to sync and added an MR in it's place [16:11] sil2100, who else can do that patch today if seb128 is not able to get to it [16:17] bfiller: will do that in a moment [16:17] pmcgowan: I can try doing it after the meeting [16:17] sil2100: thanks [16:21] bfiller: reconfigured [16:22] sil2100: ty [16:23] kenvandine: sorry just had to have our bird put down, yeah were not landing stuff till gates are open ie ota 4 is out of the door [16:24] kenvandine: I'm going to check what more we need to do now but I had to rush off [16:24] sil2100: getting this error https://ci-train.ubuntu.com/job/ubuntu-landing-008-1-build/230/console [16:24] sil2100: maybe address-book needs to be deleted from the silo first? [16:25] bfiller: hmm, no, it doesn't seem to be related... I think what happened is that you're trying to release a vivid package from a trunk that's wily based [16:25] davmor2, no worries, just checking on it [16:25] So, it seems the MR you created was against the main devel trunk from which you were releasing wily packages [16:26] bfiller: you would need to branch it off to another trunk [16:26] sil2100: want it to be off main trunk [16:27] sil2100: want wily and vivid to be in sync, both with trunk + this MR [16:27] bfiller, trunk has 15.10 version numbers though [16:27] https://wiki.ubuntu.com/citrain/LandingProcess#My_project_had_only_stable_features_but_now_it_will_diverge <- this seems to be the case here [16:27] bfiller: give me a moment [16:28] imo if we aren't diverging, we should be landing with 15.04 version numbers [16:28] but too late now [16:32] rsalveti: ping [16:32] rvr: pong [16:32] rsalveti: Hey. I'm trying to test silo 3, lxc config [16:33] rsalveti: After installing the package using adb shell in recovery, I still see an apparmor denial to Cut the Rope [16:33] rsalveti: How can check that the config was correctly installed? [16:33] rvr: which one are you getting? [16:34] rsalveti: proc/ged [16:34] i thought jdstrand uploaded a fix for that [16:35] the fix is in lxc-android-config [16:35] for arale [16:36] rsalveti: Jun 8 16:34:50 ubuntu-phablet kernel: [ 9063.511382] type=1400 audit(1433781290.430:170): apparmor="DENIED" operation="open" profile="com.zeptolab.cuttherope.free_cuttherope_0.5.3" name="/proc/ged" pid=7678 comm="qmlscene" requested_mask="r" denied_mask="r" fsuid=32011 ouid=0 [16:36] http://paste.ubuntu.com/11651958/ [16:36] rvr: is this on arale? [16:36] rsalveti: So I'm trying to verify whether the config was correctly installed or not [16:36] rsalveti: Of course [16:36] also, can you check if you have the package installed? [16:36] cat /usr/share/apparmor/hardware/graphics.d/apparmor-easyprof-ubuntu_k95v2 should tell you that [16:37] /proc/mtk_mira r, [16:37] /proc/ged r, [16:37] kenvandine: there you go marked now that I know too :) [16:37] davmor2, cool, thx [16:38] hm, wonder if the cache was generated again [16:38] rvr: did you reboot after installing it? [16:38] rsalveti: I had too, I was in recovery mode. Let me reboot again. [16:39] phablet@ubuntu-phablet:~$ grep /proc/ged /var/log/syslog [16:39] phablet@ubuntu-phablet:~$ [16:39] my arale seems fine [16:39] ogra_: this is only with cuttherope [16:39] oh ? how can that be [16:39] if access to /proc/ged is allowed systemwide [16:40] aha ! [16:40] i just had not any apps started since last boot :P [16:40] phablet@ubuntu-phablet:~$ grep /proc/ged /var/log/syslog [16:40] Jun 8 18:40:10 ubuntu-phablet kernel: [ 2831.794509] type=1400 audit(1433781610.610:289): apparmor="DENIED" operation="open" profile="google-plus.ogra_google-plus_0.2.1" name="/proc/ged" pid=8714 comm="qmlscene" requested_mask="r" denied_mask="r" fsuid=32011 ouid=0 [16:42] rsalveti: Jun 8 16:41:59 ubuntu-phablet kernel: [ 170.538965] type=1400 audit(1433781719.710:162): apparmor="DENIED" operation="open" profile="com.zeptolab.cuttherope.free_cuttherope_0.5.3" name="/proc/ged" pid=4327 comm="qmlscene" requested_mask="r" denied_mask="r" fsuid=32011 ouid=0 [16:43] rsalveti: After reboot :-/ [16:43] rvr, start some other (web)app [16:43] unless something else broke, let me check with mine [16:43] phablet@ubuntu-phablet:~$ grep ged /usr/share/apparmor/hardware/graphics.d/apparmor-easyprof-ubuntu_k95v2 [16:43] phablet@ubuntu-phablet:~$ [16:43] not even in my file here [16:44] Jun 8 16:43:47 ubuntu-phablet kernel: [ 278.749758] type=1400 audit(1433781827.920:168): apparmor="DENIED" operation="open" profile="com.ubuntu.developer.webapps.webapp-amazon-int_webapp-amazon_1.0.10" name="/proc/ged" pid=4583 comm="webapp-containe" requested_mask="r" denied_mask="r" fsuid=32011 ouid=0 [16:44] rvr, right [16:44] it isnt app sepcific [16:44] *specific [16:46] ogra_: right, the fix is in silo 3 [16:46] which is what rvr is trying to validate [16:46] Exactly [16:47] ii lxc-android-config 0.225 all [16:47] rsalveti, ah, well, i guess he needs to manually re-gen the rules then [16:47] yeah, wonder why that not happened [16:47] ATTENTION! Please don't publish anything to the overlay PPA temporarily! [16:47] was able to reproduce it here, let me remove my cache [16:49] bfiller: ok, I'm back for your service - so, basically, you want to release that one MR to both vivid and wily, yes? [16:49] Jun 8 13:49:29 ubuntu-phablet kernel: [ 57.317567] type=1400 audit(1433782169.518:187): apparmor="DENIED" operation="open" profile="com.zeptolab.cuttherope.free_cuttherope_0.5.3" name="/proc/ged" pid=3658 comm="qmlscene" requested_mask="r" denied_mask="r" fsuid=32011 ouid=0 [16:49] hm, even after a cache rebuild [16:50] wonder if this is because it's coming from custom [16:50] jdstrand: might need your help here [16:50] rsalveti, the writability of /proc/ged isnt comiong from custom [16:50] it should just allow access system wide [16:50] cuttherope and possible the cache for it, is coming from custom right? [16:51] sure, but cuttheope should have any rules for /proc/ged [16:51] and should just inherit from the device rule which should allow systemwide access [16:51] robru, kenvandine, Mirv: please don't land anything to overlay for now [16:51] sure, but I mean, if the cache is newer than the file, it will not be updated [16:51] and the denial will still happen [16:51] sil2100, ok... did i screw something up? [16:51] sil2100, or closing landing gates again? [16:52] man, it's super fast to update the apparmor cache on arale [16:52] rsalveti, didnt you just say you manually regenerated the cache ? [16:52] ogra_: yup, but just for the system/rootfs [16:52] kenvandine: well, no, we need to close them for a moment since we need to do a snapshot of the overlay, seems like the overlay wasn't snapshotted [16:52] I just remembered we also have the same for custom [16:52] sil2100, ok, i just published that security fix :/ [16:52] kenvandine: so we need the archive to have the exact same state as the last image - the content-hub upload was bad timing, but well, you didn't know so no harm done ;p [16:53] * ogra_ thinks this is likely pointless to test out of context of an image build [16:53] We can live with that additional fix I suppose [16:53] rvr: ogra_: yeah, that's it [16:53] rsalveti, so if built into the image it should "theoretically" just work :) [16:53] sil2100, it's safe... and fixes a cve :) [16:53] after rebuilding custom [16:53] well [16:54] bumping the build id [16:54] rvr: sudo rm -rf /custom/cache/apparmor/* /var/cache/apparmor/* [16:54] rvr: then reboot [16:54] you dont even need to rebuild it [16:54] just making sure the id is bumped so the image build will pick it up, no ? [16:56] rsalveti: Checking === tvoss|dinner is now known as tvoss [17:01] hum [17:01] kenvandine, do you know if issues from https://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-wily-armhf/79/console are know by ci? [17:01] "/tmp/hooks/A20bump_version_autopilot: line 18: dch: command not found" [17:01] cihelp ^ [17:01] that's the CI output on https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/wifi_activate_on_click/+merge/261425 [17:03] seb128, that doesn't look good [17:03] indeed not... [17:03] CI was working for wily branches friday [17:04] rsalveti: Gone after removing that [17:04] rvr: great [17:04] Even with amazon [17:05] rsalveti: Does it mean the silo is good? [17:05] so once we upload it, someone will need to regenerate the custom tarball to include the new cached files [17:05] rvr: yes === alan_g is now known as alan_g|EOD [17:18] sil2100: hi, I will change the target of silo 6 (row 28) to be wily. Is it mandatory that QA verifies landings on wily, or is it optional? [17:19] sil2100: silo 3 looks good, let me know when it is a good time to approve it [17:33] robru: hi, I will change the target of silo 6 (row 28) to be wily. Is it mandatory that QA verifies landings on wily, or is it optional? [17:34] boiko: qa only necessary for vivid currently [17:35] robru: ok, I changed the silo target to wily, would you mind reassigning/updating it? [17:36] boiko: sure [17:37] rvr: not yet, give us some time still [17:37] cihelp: halp, there's something wrong with the ubuntu-system-settings ci. "dch: command not found" https://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-wily-armhf/79/console [17:37] kenvandine, ^^ [17:38] jgdx: taking a look [17:38] psivaa, thanks! [17:38] jgdx: yeah, seb128 asked cihelp about that earlier [17:38] psivaa, thx! [17:38] kenvandine, you know what happened with that inquiry? (lack of a better word) [17:39] none [17:39] so glad psivaa responded this time :) [17:39] robru: hey, do you know if slangasek will be around today? [17:39] robru: thanks a lot! [17:40] boiko: you're welcome [17:40] sil2100: haven't heard anything [17:41] sil2100: hi there [18:05] slangasek, robru: no meeting today? Not that I'm not busy with firefighting ;) [18:05] sil2100: yes that's right [18:05] sil2100: oh I forgot. [18:05] sil2100: oh, it is that time, isn't it [18:05] I'm the only one there :) [18:35] cjwatson, slangasek: I'm copying the binaries from overlay to the snapshot PPA now, so far so good [18:35] Will take a while though [19:15] seb128, pmcgowan: ok, I'm way past my EOD now so I just want to finish up and go rest up a bit - the snapshotting took some time... but I checked the langpack things and it seems fairly easy to do, I'll fix that up tomorrow [19:15] robru, Mirv, kenvandine: I copied the packages to the snapshot PPA, you can land things to the overlay PPA again [19:15] sil2100: thanks! [19:22] o/ [19:26] cjwatson: hi, would it be possible to trigger a rebuild of this failed build: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-006/+build/7521819 [19:27] cjwatson: I would prefer that over rebuilding everything just because of one flaky test [19:28] robru: maybe you have permissions to do that too ^ [19:32] boiko: cjwatson: on it [19:34] robru: thanks! === tvoss is now known as tvoss|test === tvoss|test is now known as tvoss [19:36] boiko: you're welcome [19:36] trainguards, can I get a wily silo for line 57 please? [19:45] tedg: got you 36 === pat__ is now known as pmcgowan [19:45] robru, Great, thanks! [19:46] tedg: you're welcome [20:17] psivaa, any luck? [20:19] jgdx: was being looked at by fginther [20:19] i couldn't figure out what that was due to [20:19] let me check [20:20] jgdx: that should be fixed now, let me try the job [20:23] psivaa, nice. Do you know what was up? [20:23] Can I re-start all failed jobs? [20:23] jgdx: the slave nodes were missing 'devscripts' [20:23] jgdx, psivaa, I think I already restarted all of the impacted jobs [20:24] was just waiting for them to complete [20:24] fginther: thanks a lot for fixing them [20:24] ahayzen, great. Thank you guys. Wonderschön [20:25] dobey: any ideas? ^ [20:25] jgdx, psivaa, I restarted jobs for https://code.launchpad.net/~jonas-drange/ubuntu-system-settings/apn-prototype/+merge/258992, https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/wifi_activate_on_click/+merge/261425, and https://code.launchpad.net/~jonas-drange/ubuntu-system-settings/fix-1441192/+merge/255402 [20:26] alecu: it seems armhf and powrpc builders are having some issues [20:26] fginther: thanks, i have again started https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/wifi_activate_on_click/+merge/261425 [20:26] ack [20:27] alecu: at least, everything builds, but segfault happens when it tries to run the test binaries [20:29] fginther, great stuff. Thanks [20:34] jgdx, looks like the amd64 builds for ubuntu-system-settings are failing because the jobs were configured to collect test results that aren't there. I'm also fixing this. [20:40] fginther, oh, okay. I haven't seen that before. [22:12] jamesh_: i don't understand what you did in silo 17. Did you upload it to wily yourself? [22:14] dobey: I doubt that's a builder issue; there's been no relevant maintenance on them [22:19] https://code.launchpad.net/~cjwatson/launchpad/do-not-expire-phone-overlay/+merge/261438 possibly relevant to the interests of some here [22:20] Hi robru o/ How's things? Might be a silly question, how do I get the autopilot silo/package moved from proposed pocket? I had the impression that I had done the needed sru things. [22:21] veebers: there's lots of steps. Did you verify the bugs are fixed and mark the bug as verification passed? [22:23] veebers: looks like one bug is tagged verification-needed still. [22:23] robru: aye, set the tag as verification-done . . Oh? Rats, seems I missed that one :-P [22:24] robru: right, sorting that out now [22:25] veebers: then you need to poke somebody from Ubuntu-sru with a pointy stick. [22:26] robru: ack, will figure out who to poke (and leave you alone ;-) ). Thanks again for the help [22:26] veebers: you're welcome! SRU's are notoriously slow, if you get it accepted in under 2 months i think you're doing well [22:27] robru: ^_^ cheers [22:28] veebers: https://bugs.launchpad.net/autopilot/+bug/1425721 is listed on http://people.canonical.com/~ubuntu-archive/pending-sru.html as v-needed too [22:28] Launchpad bug 1425721 in autopilot (Ubuntu) "Extension classes with multiple base classes aren't merged correctly." [Undecided,New] [22:28] (not that I'm effectively ubuntu-sru any more, I'm just still in that team so that I could do some code fixes, should probably leave it again) === salem_ is now known as _salem [22:41] cjwatson: ah I see, ack thanks for clarifying :-) [22:53] robru: hey, the dashboard says address-book-app is in the proposed pocket for silo 31, but I can't see it in the excuses page [22:55] boiko: Hmmmmmmm that is strange considering i published it 3 hours ago [22:58] kenvandine: hi, bdmurray has brought it to my attention that there are two different "systemd-shim 9-1bzr3" packages now that were built in different silos - one in silo 035 for vivid and copied to the stable-phone-overlay ppa, one in silo 001 for wily and published to wily [22:58] cjwatson: infinity: Hmmmmmmm, excuses page seems to be 6hrs stale, can somebody check on that? [22:58] kenvandine: can you help us understand how this happened?