=== salem_ is now known as _salem [00:41] robru: hey if you're still around. I've used "citrain device-upgrade " and now my device doesn't boot past the bq screen. Have you seen this before? [00:52] veebers: what version of phablet-tools-citrain do you have installed? [00:52] veebers: and in the log did you see citrain tool uninstalling the entire world? === _salem is now known as salem_ [01:01] veebers: I fixed a ton of bugs in citrain tool recently, make sure your installed version has an october timestamp in it. Install from phablet-team/tools or sdk ppa [01:02] veebers: or update to xenial ;-) [01:17] robru: hah, ok will check version etc. [01:18] robru: (in a step I should have taken earlier) looking at the output I see: [01:18] The following packages will be REMOVED: [01:18] ubuntu-touch ubuntu-touch-session unity8 unity8-common [01:18] veebers: yeah that sounds like the bug I fixed. [01:18] veebers: alright I gotta run but will be back in ~2 hours if you ned any more help [01:18] robru: ack, cheers. Will install from ppa === salem_ is now known as _salem [02:08] michi__: Agreed that it's click's problem, though not a missing dependency. Analysis in the bug. [03:08] veebers: ok I'm back, did you get everything working? [03:09] robru: aye, using the ppa worked [03:10] veebers: great === chihchun_afk is now known as chihchun [08:46] cihelp: i see some settle_before and settle_after failures in this MR, mixed with AP test failures. should i worry about the tests or just re-run the job before having a look ? https://code.launchpad.net/~uriboni/webbrowser-app/tabs-use-haptics/+merge/275726 [09:06] nerochiaro: it actually depends on the failures. if you'd want to rerun and see if the failures are reproducible then that's fine, but taking a look at the failures are always recommended [09:07] psivaa: the reason i ask is because i become skeptical of failures in tests when i see mixed with them failures in infrastructure [09:07] nerochiaro: which are the infrastructure failures? [09:10] psivaa: settle_before and settle_after, like this: https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/3886/testReport/junit/%28root%29/webbrowser_app/settle_before/ [09:13] nerochiaro: I would not consider this to be an infrastructure failure, the system_settle failures should also be investigated as regular failures especially when there are all passes in the runs before and after this particular run. [09:13] psivaa: how do i investigate them ? [09:13] nerochiaro: they could be transient (or flaky) failures, but that needs to be confirmed [09:14] nerochiaro: re-running the job with the same parameters in this case would confirm if they are transient [09:14] psivaa: i'll request a re-run [09:20] nerochiaro: and i see that there are no settle_after/ settle_before logs for those failures, which would make investigating those failures impossible, but please note that there are some crash files here: https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/3886/artifact/clientlogs/webbrowser_app/ [09:20] psivaa: are they from that same test run ? [09:21] nerochiaro: yes [10:22] brendand, yeah, it's all slowly migrating now [10:23] seems unity8 is the last to migrate, testing unity-scope-click now [10:40] Saviq, Are you sure unity-scope-click is running? It has been in this state for a while and I don't see it on http://autopkgtest.ubuntu.com/running.html [10:40] or maybe it is just still waiting for an executor [10:41] jibel, it says it's running ;) [10:42] Saviq, yeah but it's strange that it's done on other arch and still running on i386 [10:42] and not listed on the "running" page [10:42] jibel, agreed [10:43] * Saviq asks pitti [10:54] jibel, pitti's looking into it, known issue [10:56] sil2100, are you the framework master these days? [10:56] Saviq: hey! Master - no, 'maintainer' - yes ;) [10:56] What's up? [10:57] sil2100, where can we find what the most recent framework included? [10:58] Saviq: that's not so easy, you would just have to see what's up the latest OTA-7 image, as frameworks do not define any hard list of pulled in deps [10:58] So it's basically whatever was in the image that first had the framework defined [10:59] sil2100, yeah, which sounds like a problem... [10:59] sil2100, how are devs supposed to know what they can safely use? [10:59] UITK 1.3 moved a long way since then (btw, the framework first appeared on rc-proposed before OTA7, but that we can probably ignore) [11:00] Saviq: true, in any case UITK 1.3 is the toolkit version to target for 15.04.1, but yeah, I suppose it might be troublesome if 1.3 had additions later on [11:01] sil2100, yes exactly, it had [11:01] and important ones [11:01] Saviq: not sure how the framework idea got invented, but quoting lool: it's a "contract without the terms of the contract" [11:03] sil2100, so... working within the constraints of frameworks as we know them today, we need to publish the list of packages that are on OTA7 [11:03] sil2100, I would plan a new framework for OTA8 already [11:04] If the number of additions/changes in 1.3, I would maybe later bump the UITK version and add a new framework for it [11:04] I mean, if the number is high [11:05] sil2100, we can't bump the 1.3 bit, there is minor version that's bumped with every release (that's actually a revision number from staging) [11:05] sil2100, 1.3 has to stay because it corresponds to "import ... 1.3" in qml [11:06] sil2100, basically 1.3 isn't completed yet (it's stable wrt. deprecations, but additions are happening all the time) [11:06] sil2100, which means "1.3" isn't precise enough [11:06] I think we need a common place where the UITK -> framework binding would be available [11:06] sil2100: nope, we will not bump the version.. as then every time new stuff is added in an OTA we will need to bump the import [11:06] i.e. what features of 1.3. are available in which framework [11:06] sil2100: and the user space on the device si limited [11:07] ugh, why do we still have 14.04 -dev1 frameworks on the phone, thought those go away :/ [11:07] sil2100: beside, every time the apps would need to adapt to the imports... so it woudl be a nightmare [11:08] sil2100: and we would have lots of unfinished work in each framework [11:08] s/framework/UITK version [11:08] sil2100, we either need to have a seed/seeds that actually depend on the packages/versions that we say a framework includes, or some place where the map is published [11:09] and we need to clear the -dev frameworks from devices... [11:09] except for the most recent one [11:11] sil2100, the current situation of "oh yeah, that framework was first published with OTA7, so whatever was there"... especially if we can't easily say what's there [11:12] the full list of packages in OTA7 is not an indicator either, because packages can come and go, a framework can only include a subset of APIs that we commit to maintaining [11:17] I never really understood the principle of how this framework model was supposed to work [11:17] I might try getting rid of the -dev ones if needed [11:18] Anyway, I suppose from a developer POV it would be best if there was a place that would say: hey, 15.04.1 framework, you can use this and that from 1.3 UITK etc. [11:18] But right now it's all a fuzzy thing [11:19] dobey: ping [11:25] sil2100, yeah, it's quite random [11:25] sil2100, UITK has an auto-generated .api file that lists all components and properties available, it's trivial to do with QML [11:26] so a set of those files could be a start [11:26] we should probably have per-framework docs, too, ideally with /since markers [11:30] +1 [11:31] I suppose that's a valid work-item for the nearest time [11:31] * sil2100 just needs to finish something before feature freeze [11:31] ;) === _salem is now known as salem_ [12:06] robru, you asked for a bug #1510515 [12:06] bug 1510515 in CI Train [cu2d] "Auto-build -gles twins" [Undecided,New] https://launchpad.net/bugs/1510515 [12:57] rvr: hi [12:57] dobey: Hi [12:57] dobey: Check card in trello [12:59] rvr: weird. sounds like online-accounts-ui is broken there maybe [12:59] dobey: Let me check without the silo === alan_g is now known as alan_g|lunch [13:00] dobey: Without the silo it works [13:00] rvr: i'm upgrading to latest image on my mako and trying again there too [13:01] rvr: without silo 26? [13:01] dobey: Sorry, without pay-ui click update [13:04] rvr: that's very odd [13:10] rvr: it's working fine here. :-/ [13:11] dobey: Which image are you using? [13:11] channel: ubuntu-touch/rc-proposed/ubuntu [13:11] on mako [13:12] #273 [13:16] dobey: arale ubuntu-touch/rc-proposed/meizu.en 148 here [13:18] rvr: i don't have an arale or bq here, but i don't see what could possibly different between meizu.en and ubuntu images, that would cause the new pay-ui click to break (which is oddly not even pay-ui breaking at that point, but online-accounts), but not with the pay-ui that's currently in the store. [13:19] dobey: I'm reflashing the arale to check pre-post/pay-ui click update [13:20] ok === chihchun is now known as chihchun_afk [13:51] trainguards, may i ask for purging of silo 4? [14:00] dobey: It fails again [14:00] dobey: Without the package, it works, the accounts dialog UI shows [14:01] dobey: With the package, it opens and closes [14:01] dobey: I install the package with pkcon --allow-untrusted [14:02] Back === alan_g|lunch is now known as alan_g [14:05] pstolowski: on it [14:05] pstolowski: you want to abandon it completely? [14:05] rvr: pkcon install-local --allow-untrusted right? [14:06] dobey: Right [14:06] sil2100, no, just start clean [14:06] rvr: weird. that makes absolutely no logical sense :-/ [14:07] dobey: untrusted-helper-pay-ui .... log [14:07] dobey: It is because the component is not trusted? [14:07] rvr: those dbus complaints are mostly meaningless and are coming from online-accounts [14:07] rvr: no, --allow-untrusted only has to do with signature verification on the package itself [14:09] mardy: Can you refresh me how to set the debug mode in the online-account service? [14:09] rvr: OAU_LOGGING_LEVEL=2 OAU_DAEMON_TIMEOUT=9999 online-accounts-service [14:10] mardy: Thanks [14:10] Given applicationId doesn't match profile [14:10] request.cpp 272 fail "com.ubuntu.OnlineAccountsUi.InvalidApplication" "Invalid client application" [14:10] rvr: is there a crash file in /var/crash for any online-accounts stuff? [14:11] huh [14:11] mardy: What does "invalid client application" mean? [14:12] sil2100, just clean the ppa please [14:12] pstolowski: ACK [14:13] pstolowski: done [14:13] pstolowski: remember to change the silo to xenial+vivid [14:14] sil2100, right, thanks! [14:14] yw! [14:15] dobey: http://paste.ubuntu.com/12979708/ [14:16] rvr: right, i don't know what that means, or why online-accounts would be doing that, but it's an issue with online-accounts, not pay-ui. i'm surprised the pay-ui that's on the image works, but the sideload click doesn't, but beyond that, i don't know what to say [14:20] josepht, hey, I didn't hear back yesterday on which way to go with the upgrade. Shall I ask for it or ? I still need to run the backup script, which I can do when we are ready [14:22] balloons: I'd go ahead and run your backup script. I'll have an answer for who should request the upgrade shortly. [14:25] balloons: you can request the upgrade [14:27] balloons: when/if you're ready you are also empowered to request a redeploy if you'd like to test that path. [14:28] trainguards: hi folks! could someone kick the ppc64el build that failed in here? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-055/+packages [14:28] josepht, ok will do. And yes, I'll test the redeploy after. Backups first! [14:28] it looks like the builder went a bit mad [14:28] pete-woods: on it [14:28] sil2100: thanks [14:28] pete-woods: rebuilding, yw! [14:34] dobey: http://paste.ubuntu.com/12979832/ [14:35] dobey: There is an extra parameter passed in the current pay-ui, windowId. Don't know whether it makes any difference. [14:35] rvr: i have no idea what any of that means. pay-ui is "unconfined" [14:35] dobey: Could you work with mardy on this? Otherwise, it's not going to land. [14:36] mardy: ^^ what is going on with rvr's device here? [14:36] * mardy looks [14:37] rvr: i can't recreate the issue on my mako, so i'm not sure what i can do other than to bug mardy about it and look at your debug info [14:38] robru, hey, something went wrong here https://ci-train.ubuntu.com/job/ubuntu-landing-021-1-build/213/consoleFull - I think the train decided it doesn't need to build u-s-c since it built it once... but it never uploaded it to the silo [14:39] robru, I think it might be because unity8 was failing to prepare a package, and u-s-c prepared it fine, so decided there's no need to rebuild, even if it didn't upload it due to the unity8 fail [14:39] dobey: can I see the code where you are requesting the account creation? At a first sight, it looks like the given applicationId is incomplete: it should be "com.canonical.payui_payui" [14:42] pete-woods,sil2100: I recommend leaving those alone for the moment - I'm working with IS to work out what's wrong with the cloud in question, and I'll be retrying in bulk once that's done [14:43] cjwatson: ok, thanks for the heads up! [14:45] mardy: looking for it. i'm not 100% sure on the path through online-accounts there, but it's not something that's changed in an incredibly long time [14:45] oh right [14:46] mardy: https://bazaar.launchpad.net/~unity-api-team/pay-ui/first-branch/view/head:/app/payui.qml#L71 [14:46] but that hasn't changed in over a year [14:47] dobey: so, what is the silo you are trying to land? [14:47] mardy: https://jenkins.qa.ubuntu.com/job/generic-click-builder-14.09-armhf/39/artifact/output/com.canonical.payui_15.01.133_armhf.click [14:48] dobey: do you have a diff from the previous version? [14:49] mardy: https://code.launchpad.net/~dobey/pay-ui/iap-support/+merge/271815 [14:51] dobey: mmm... cannot see anything wrong in it... [14:51] rvr: could it be that you have also some other silo installed? [14:51] mardy: I didn't install any silo, just the click package [14:51] mardy: indeed, the Setup{} hasn't changed, and i don't have this issue on my mako [14:52] rvr: can you try reinstalling the old version of the click package? [14:52] mardy: I did reflash the phone [14:52] mardy: Problem gone. With the click package, fails. [14:53] rvr: I wonder if it could be a problem with the online accounts hook; can you install the old click version, after having installed the new one? [14:54] dobey: Where can I download the current click package? [14:54] rvr: the store [14:55] dobey: meanwhile, please try appending a "_payui" to that applicationId string; it should fix the issue [14:55] popey: ^^ you had a separate repo of all the free clicks that are in the store, right? [14:55] i do. [14:55] popey: where was it? [14:56] http://popey.mooo.com/mirror/clicks/ [14:56] rvr: http://popey.mooo.com/mirror/clicks/2015/04/2015-04-30-050001/com.canonical.payui_15.01.120_armhf.click [14:56] Nice [14:56] Thanks [14:57] * popey adds one to the 'number of times that mirror has come in handy' counter [14:58] mardy: dobey: It just works [14:59] wtf :( [15:00] rvr: and can you please get me the usual logs (as per command above) with the old click? [15:01] mardy: This is with the new click http://paste.ubuntu.com/12979708/ [15:01] mardy: With the old http://paste.ubuntu.com/12979817/ [15:04] rvr: can you please do "ls ~/.local/share/accounts/applications/com.canonical.payui*" and "cat ~/.local/share/accounts/applications/com.canonical.payui*" ? [15:04] phablet@ubuntu-phablet:~$ ls ~/.local/share/accounts/applications/com.canonical.payui* [15:04] /home/phablet/.local/share/accounts/applications/com.canonical.payui_payui.application [15:05] mardy: http://paste.ubuntu.com/12980127/ [15:06] rvr: ok, I think I got it [15:06] mardy: you understand why it's breaking now? [15:06] rvr: my feeling is that hooks are not properly executed when updating a preinstalled app [15:07] rvr: so, even after you install the new click, the /home/phablet/.local/share/accounts/applications/com.canonical.payui_payui.application file contains the apparmor profile for the old app [15:07] rvr: I should make the OA check ignore the version number [15:07] sil2100: you asked me a question last night during my dinner. still need an answer? [15:07] mardy: i think that .application file is with the old click installed though [15:08] mardy: I installed the new click package [15:08] rvr: can you pastebin the contents of that file after installing the new click again? [15:08] mardy: cat ~/.local/share/accounts/applications/com.canonical.payui* gives the same results as the original click [15:08] huh [15:08] rvr, dobey: yep, so either the hook is not executed, or it fails somehow [15:08] mardy: http://paste.ubuntu.com/12980179/ [15:08] barry: I suppose, it wasn't anything super urgent but I was just wondering about the description feature ;) [15:09] how [15:09] barry: since I know we're not really using that in the touch images at all [15:09] rvr: can you manually run online-accounts-hooks and see if the file changes afterwards? [15:09] rvr, dobey: sorry, have to run out now, will be back tomorrow morning [15:09] rvr: you are not running pkcon install-local with sudo are you? [15:09] mardy: online-accounts-hooks doesn't do anything [15:09] dobey: Nope [15:09] sil2100: right. so that was basically an early requirement that never really panned out. we even had support for i18n descriptions but that never happened either [15:10] rvr: can you try rebooting after installing the new click and then see if the .application file contents still point at the pre-installed app? [15:11] dobey: I did that and nothing changed, but doing it again [15:12] hmm [15:13] rvr: what does "ls -lh .local/share/accounts/applications/com.canonical.payui_payui.application" say? [15:18] does anybody know who is the best (from maybe cihelp) around here I could ask about Breaks/Conflicts/Replaces? [15:18] dobey: -rw-rw-r-- 1 phablet phablet 662 oct 27 14:22 .local/share/accounts/applications/com.canonical.payui_payui.application [15:20] huh, ok [15:20] bzoltan_: #ubuntu-packaging probably the best place to ask [15:21] dobey: what a descriptive channel name :D thanks [15:22] dobey, thanks for answering, I was going to suggest a core-dev, but that sounds better [15:23] Saviq, is there a recommended image channel for testing xenial builds of unity8 on the phone? [15:24] are there xenial images being built yet? [15:25] fginther, there isn't a xenial channel yet afaict... sil2100? [15:26] fginther, but it would be ubuntu-touch/devel-proposed/ubuntu [15:27] rvr: and the file is still broken after a reboot? [15:27] None yet, maybe it's time to finally start building those images [15:27] dobey: Yes [15:27] Saviq, that was my expectation. If it's not ready yet for the unity8 testing, we can hold off on adding that bit until it's ready [15:27] rvr: what does "click list | grep payui" say? [15:27] dobey: com.canonical.payui 15.01.133 [15:28] rvr: what version of the "click" debian package is installed? [15:37] dobey: 0.4.40+15.04.20151006-0ubuntu1.1 [15:38] well bugger :( [15:46] rvr: so, this looks like the bug that should have been fixed by that version of click, resurfacing somehow [15:46] kyrofa_: ^^ any ideas? === kyrofa_ is now known as kyrofa [15:48] * kyrofa reads scrollback and wonders why his nick had an underscore [15:48] netsplits are fun! [15:49] anyway, i am starving and need to get lunch. bbiab [15:57] sil2100: hey just noticed something odd, so robert-ancell placed a new xorg package in stable-phone-overlay ppa...and on my device i did update/dist-upgrade [15:58] but it's still on the "old" xorg (this is for xmir) [15:58] kgunn: maybe he published the wily/xential version to the PPA? Or did he push the vivid package? [15:58] Let me check [15:58] sil2100: maybe it's priority pinning ? [15:58] https://pastebin.canonical.com/142782/ [15:59] it's there ^ just not the installed version [15:59] hmmm [16:00] and this is obviously ubunt-pd [16:00] The pin priority is obviously wrong there, it's 50 instead of higher [16:00] kgunn: check the apt/preferences.d if everything is ok there [16:03] dobey: However, running online-accounts-hook doesn't do anything, does it need any parameter? [16:07] dobey, interesting... I'm not sure I understand what's happening here though. I don't see a click hook that generates the .local/share/accounts/applications though. Where do they come from? [16:07] rvr, ^^ [16:08] kyrofa: There is a .application file in the click package, but I have no idea beyond that fact [16:12] "hooks": { [16:12] "payui": { [16:12] "account-application": "com.canonical.payui_payui.application", [16:12] kyrofa: I guess is that one [16:13] rvr you're right-- that one creates the online-accounts-hooks and then runs the online-accounts-hooks binary... which must generate those .application files somehow? [16:13] * sil2100 jumps out for practice [16:14] kyrofa: Probably [16:15] I'm not familiar with online-accounts-hooks. However, dobey if you're referring to bug #1479001, I'm not sure these two things are related. The fix for that bug doesn't even happen until reboot. This sounds like an upgrade gone bad or something [16:15] bug 1479001 in Canonical System Image "Older version of a user installed click is not updated by custom or base pre-installed clicks with a more recent version" [Critical,Fix released] https://launchpad.net/bugs/1479001 [16:15] The mediascanner2 silo needs a binNEW review, we'll poke someone about that in a bit [16:16] rvr can you verify that the .application file in the click package was actually updated between the two versions? [16:17] kyrofa: Well, the issue we have is that the content of the .application file is not updated with the correct click package version [16:18] kyrofa: so online-accounts-service fails matching the application request [16:27] sil2100: sorry, got otp for a bit... [16:28] so yeah, my pref file clearly shows Pin-Priority: 50 [16:28] which would seem wrong [16:29] hmm...i did run citrain tool [16:29] i've another device....it shows [16:29] Pin: release o=LP-PPA-ci-train-ppa-service-stable-phone-overlay [16:29] Pin-Priority: 1001 [16:30] lemme add a ppa with citrain and see what happens [16:38] yeah citrain appears to be altering the pin priority incorrectly [16:44] sil2100, hey, my silo is set for xenial, but build log has this: http://pastebin.ubuntu.com/12980779/ ; anything to be worried about? [16:52] sil2100, uh oh i've plethora of issues with silo 4 today - all projects in the silo seem to fail on xenial - ppc64el; on vivid it fails on missing dependencies such as libandroid-properties-dev - see https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-004/+build/8197298 [16:52] sil2100, any idea? [17:01] kyrofa: yeah, so, i'm referring to the hooks not being run right when a package is upgraded. [17:02] anyway, i don't know what to do about that [17:02] rvr: can you rm the .application file in .local/share/, then reboot, and see if the issue still happens? [17:06] dobey, yeah I assume user hooks are run upon install. My only guess is that the online-accounts-hooks binary is failing somehow [17:07] well i presume rvr is gone for the day now [17:08] whom can i get to test pay-ui and the other silo now? alesage i guess? [17:09] dobey: Ok, removing the file and restarting does the trick [17:09] com.canonical.payui_payui_15.01.133 [17:09] /opt/click.ubuntu.com/.click/users/@all/com.canonical.payui [17:09] com.canonical.payui_payui_15.01.133 [17:10] ok [17:10] com.canonical.payui 15.01.133 [17:11] dobey: And online accounts dialog appears [17:11] ok [17:11] let's file a bug against click/online-accounts about the hook issue and not have it block pay-ui please? [17:15] dobey: No way [17:15] dobey: We will be releasing this to real users. Without fixing this problem, we won't release the new pay-ui. [17:15] sil2100, following doko's email about xenial, i've opened a bug for constant failures on ppc64el: https://bugs.launchpad.net/launchpad-buildd/+bug/1510637 [17:15] Launchpad bug 1510637 in launchpad-buildd "Build fails all the time on xenial ppc64el with no log" [Undecided,New] [17:16] so pay-ui has to fall on the sword, because you happened to hit a bug in click/online-accounts on your one device? [17:16] dobey: We don't know whether the fix will be in time or not [17:16] bfiller, silo 47 is now top approved. [17:16] sil2100, not sure about other architectures though, where it fails on dependencies such as libandroid-properties-dev, libhardware-dev, qtdeclarative5-ubuntu-web [17:16] dobey: If not, this will break real phones [17:17] because .application won't be recreated [17:17] rvr: that's funny. it's not broken on my phone [17:17] dobey: Have you flashed the phone with --wipe? [17:19] so until this is fixed, all click packages will be blocked by QA then, right? [17:20] dobey: If their test plans don't pass, yes [17:22] ... [17:26] sil2100: ppc64el> all fixed now, everything retried [17:26] sil2100: you may want to do watch-only builds or whatever [17:26] pstolowski: that's fixed now [17:26] pstolowski: the ppc64el bit anyway [17:27] pstolowski: and those dep-waits should be harmless assuming the packages failed before [17:27] cjwatson, cool, thanks for update [17:30] cjwatson, i'm not sure what do you mean with the dep-waits.. are you referring to https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-004/+build/8197301 ? do you mean it should work now when i retry? [17:30] pstolowski: I mean the ones in vivid [17:30] libandroid-whateveritwas [17:31] pstolowski: oh, well that too - you don't need to retry that, it's not a relevant failure because unity8 never built on powerpc [17:31] dobey: I have created a bug https://bugs.launchpad.net/canonical-devices-system-image/+bug/1510640 [17:31] Launchpad bug 1510640 in pay-ui "PayUI unable to log in Ubuntu One" [Undecided,New] [17:32] why is that a bug in pay-ui? [17:32] pstolowski: I believe the only thing that needs to finish now is https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-004/+build/8197296, which would retry by itself eventually but I'll hurry it along as soon as it's possible to do so [17:33] cjwatson, ack, thanks [17:33] moved it to click === pstolowski is now known as pstolowski|afk [17:35] dobey: I was adding all the projects involved :P [17:46] kgunn: sil2100: yes citrain tool alters the pins so that it can install a silo without pulling in extra updates from overlay ppa. That is the correct behavior. If you want to dist-upgrade after installing a silo you need to clear the pin file. [17:47] robru: yeah that makes sense now [17:47] Saviq: yeah I tweaked that behavior a bit but it's obviously not quite right yet [17:54] kyrofa: Do you think pay-ui's problem lies in online-accounts or in the click tool, not executing the hook? [17:55] rvr I feel like there would be other symptoms if click wasn't running hooks. I'm leaning toward online-accounts [17:55] Because it supplies the hook that being run [17:56] can anyone else replicate the issue? [18:00] dobey, rvr: so, the online-accounts-hook checks the date of the .application file specified in the hook and the date of the generated file. Maybe something goes wrong with that check? [18:01] dobey: http://bazaar.launchpad.net/~online-accounts/ubuntu-system-settings-online-accounts/trunk/view/head:/click-hooks/main.cpp#L342 [18:02] mardy: If my deb visor is not mad, the date of the .application file inside the click package is Oct 1st [18:02] rvr: can you please do a "ls -l ~/.local/share/online-accounts-hooks/"? [18:02] but what is the date of the file in the image? it should be from april [18:02] rvr: actually: ls -l ~/.local/share/online-accounts-hooks/*.application [18:03] mardy: We recreated the file removing the old [18:03] but apparently it was today [18:03] 11:16 < rvr> dobey: -rw-rw-r-- 1 phablet phablet 662 oct 27 14:22 .local/share/accounts/applications/com.canonical.payui_payui.application === alan_g is now known as alan_g|EOD [18:04] i don't know if that date is the same as what's on a clean image though [18:06] pstolowski|afk: ok, so perhaps you have some genuine failures now, or maybe somebody needs to take a look at that silo since the failures don't seem to correspond to something actually published in the PPA [18:07] ubuntu=20151027 <- where does the tarball for this come from? [18:07] ah in /pool [18:08] which is incredibly huge list [18:14] mardy: it checks the date of the source files, or of the currently generated file? [18:14] dobey: both, it compares them [18:14] mardy: well that's not nice [18:15] i wonder how many click hooks are doing that [18:15] dobey: isn't that reliable? [18:16] mardy: no, because on a freshly flashed device, the timestamp of the generated file is set when it first boots up after flashing, and not to the timestamp of the source file it was generated from. so the generated file gets oct 27 2015 as the date, but the source file was mar 31 2015 [18:17] and then if it compares the generated file's date to the source file of the new package, the file that's actually older, will appear newer [18:21] mardy: so i guess that if() block just needs removed [18:22] hooks should be setting the timestamp of generated files to be equal to that of the source file, as a general rule [18:23] dobey: wait a second... actually the source file is a symlink, created by click [18:23] huh? [18:23] no, the source file is the .application file in the click package [18:24] if you're getting to that data via symlink, then you should be resolving the link so that you read the target file's info, and not the symlink's [18:25] dobey: no, actually I do really want to get the symlink's date [18:25] dobey: because that tells me when the click was installed [18:26] well either way, the generated file's date is not the same as the source file's date (whether that be the actual source, or the symlink) [18:26] if the generated timestamp is only >= the source timestamp rather than ==, then it's much much harder to reliably update it when the original changes - because the original might become newer, but not as new as the generated file [18:28] but how has this literally not been a problem for us for the last 15 months, and is only appearing now? [18:28] this can't possibly be a new bug [18:28] sort of thing that happens in corner cases that it's hard to get anybody to care about until they happen [18:28] I've definitely seen similar kinds of things in other hooks before [18:29] or it gets papered over somehow [18:30] yeah, i mean, we've released multiple fixes to pay-ui since july last year, so i'm just very surprised that this would be the first time this has happened. or for any other click packages that use any online accounts [18:31] cjwatson: ok, so you recommend setting the time of the generated files to be the same as the source files, and re-generated them everytime we see that they are different? [18:32] mardy: so i guess i should assign bug #1510640 to you? [18:32] bug 1510640 in ubuntu-system-settings-online-accounts (Ubuntu) "PayUI unable to log in Ubuntu One" [Critical,New] https://launchpad.net/bugs/1510640 [18:33] dobey: I think so, thanks [18:33] dobey, rvr: but this shouldn't block the new payui from landing [18:34] mardy: that's generally what I've found to be more robust. disclaimer: haven't looked into this bug in detail [18:34] cjwatson: makes a lot of sense anyway, I'll try that, thanks === chihchun_afk is now known as chihchun [18:36] mardy: thanks for coming back to look at this [18:37] dobey: yw :-) [18:37] is rvr still around? or should we prod alesage or ToyKeeper to prod this landing back to life? === pstolowski|afk is now known as pstolowski [18:55] cjwatson, how long does it take for packages to show up in the ppa? i've rebuild another package in silo 4, it's available for xenial for 17 minutes, but not for vivid [18:56] pstolowski: details so that I can grep, please? [18:56] cjwatson, unity-scopes-shell here https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-004/+packages [18:56] 2015-10-27 18:24:16 INFO Upload was rejected: [18:56] 2015-10-27 18:24:16 INFO File unity-scopes-shell_0.5.5+15.04.20151027.1.orig.tar.gz already exists in Landing PPA 004, but uploaded version has different contents. See more information about this error in https://help.launchpad.net [18:56] /Packaging/UploadErrors. [18:56] 2015-10-27 18:24:16 INFO File unity-scopes-shell_0.5.5+15.04.20151027.1-0ubuntu1.diff.gz already exists in Landing PPA 004, but uploaded version has different contents. See more information about this error in https://help.launchpa [18:56] d.net/Packaging/UploadErrors. [18:57] 2015-10-27 18:24:16 INFO Files specified in DSC are broken or missing, skipping package unpack verification. [18:57] pstolowski: ^- version clash, fix that [18:58] perhaps it is confused because the package was previously there but was then removed [18:58] I expect you need to get it to bump to 20151027.2 somehow (for which you'll need a trainguard, I can't help further on that) [18:59] cjwatson, ok, i'll just bump the micro version in the changelog, should have done that anyway. thanks! [19:00] eod [19:00] wait what? train should be generating that number... [19:05] somebody apparently manually deleted the vivid version from the ppa so the version numbering code is getting confused. === chihchun is now known as chihchun_afk === salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem [21:49] robru, hey, did you see my msgs before about "build" not working as expected after a failed prepare? [21:49] robru, train skips unchanged packages regardless if they've been uploaded to silo or not [22:28]