=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [08:05] hi trainguards: i'm trying to see what to do about https://requests.ci-train.ubuntu.com/#/ticket/1545#audit_log [08:06] in particular, if i need to rebuild / land normally, as i remember this silo having been used already to unblock the arm64 builds [08:18] dbarth: well it surely looks the webbrowser-app build is 4 days old and needs a rebuild. not really sure about the arm64 part but I don't see anything old lingering in the PPA. [08:24] dbarth: IIRC this silo would be nice to have but is not super required as we changed the necessary deps to get rid of the ubuntu-html5-theme old package [08:25] ahh [08:25] dbarth: this is just for upgrade paths [08:25] ok, well, i'll rebuild and push anyway then [08:25] i wanted to avoid pushing something already semi-applied or something [08:25] thanks for the confirmation === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [09:13] ogra, https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1604611 [09:14] Launchpad bug 1604611 in webbrowser-app (Ubuntu) "[webapp-container] Undocumented command line option --no-australia-mode" [Undecided,Invalid] [09:14] mzanetti, HAHAHAHAHAHAHAHAHAHA !!!! [09:14] what a great morning :D [09:20] brilliant [09:31] Oh my [09:31] ogra: now look what you've done! [09:31] :) [10:05] uh oh.. [10:14] I'll let sil2100 handle that mystery triple-really-xenial silo :) [10:14] ;) [10:15] Yessss, it's 3vil [10:15] Especially that I already sense that address-book-app will require some special handling in the archive in yakkety [10:27] doh, I'm over PPA size limit, no wonder my uploads didn't show up :( https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-024/+packages [10:27] posted https://answers.launchpad.net/launchpad/+question/298263 [11:03] thanks to Colin [11:19] Mirv: eh, I think I need to publish this silo 'by hand' [11:20] Since I guess it's expecting me to add yakkety and vivid landings for the other packages [11:21] so it is [11:22] That sucks a bit [11:27] jibel: https://requests.ci-train.ubuntu.com/#/ticket/1697 with hugs. [12:30] Kaleo: ping === _salem is now known as salem_ [12:56] boiko: ping [12:56] rvr: pong [12:56] boiko: Hi [12:57] boiko: I'm checking silo 41 [12:57] rvr: hello :) [12:57] boiko: Do you know exactly what to look for async_bottom_edge? [12:59] rvr: salem_ knows more about that one, but I would say to test if bottom edge works in phone mode [12:59] boiko: That's working, yes [12:59] salem_: ^ [13:00] salem_: what was the case to invoke it from the url dispatcher? [13:03] rvr, boiko open messaging-app via dialer and address-book [13:16] sil2100, hey ... so address-book-service despite my packaging review/need to fix from yesterday?! it's fine but no need to ask me for reviews anymore from this point on this apparently things keep landing ignoring review comments [13:16] kenvandine, ^ there is your name on those so just as fyi [13:17] sil2100: I wonder why ubuntu-touch/staging/ubuntu images older than 31 are missing? I'm trying to bisect when the xenial worked [13:17] seb128, oh? i didn't look at the merge proposal again just the diff [13:18] kenvandine, which is missing replaces for files moved between binaries [13:18] which I pointed yesterday when asked for review [13:18] shrug [13:18] also the e-d-s-ubuntu naming sucks [13:18] it's not descriptive on what that package is or does [13:19] which branch did you comment on? [13:19] none, I was pinged on this IRC channel [13:20] I don't even know which branch correspond [13:20] Lucasz gave me a url to the packaging diff artifact [13:24] seb128, i'm surprised it updates cleanly without the replaces [13:24] depends of the binaries unpack order [13:24] it's moving between debs [13:24] dbarth: hey! [13:24] dbarth: are you around? [13:24] sil2100, sure ignore me [13:24] seb128, yeah [13:24] i just would think it would install the new package first to satisfy the depends [13:24] seb128: uh oh! I didn't land it! [13:25] which would then break [13:25] sil2100, i did... :/ [13:25] seb128: it was broken so I didn't touch it! We don't have any real means to reject it in the train [13:25] didn't know seb128 had an issue with it [13:25] but seb128 was clearly right :) [13:25] the train has a "verification" section no? [13:25] we could flag it as failing verification [13:26] seb128, btw... looks like the ppc64el issue is gnome-settings-daemon needing nautilus-data:ppc64el [13:26] seb128: hm, yeah, I could, but it's a QA field, but yeah, I could have just used it - I *assumed* that since it requires a binNEW from an archive admin then no one will publish it withou an approval of an archive admin [13:26] kenvandine, that binary is arch all [13:27] sil2100, binNEW doesn't need pre-review [13:27] Since no one publishes binNEW packages without an explicit ACK [13:27] you are confusing it with sourceNEW [13:27] seb128: in the train procedures we do that [13:27] There's always a warning [13:27] coredev can publish new bins no? [13:27] kenvandine, ^ [13:27] gnome-settings-daemon:ppc64el : Depends: nautilus-data:ppc64el (>= 2.91.3-1) but it is not installable [13:27] They can, yes, but they should always consult archive admins first [13:27] That's why I did that [13:27] kenvandine, dunno what's going on there [13:28] yeah... i should have caught the issue, but there was no way to track that another dev had nack [13:28] next time I just free the silo :p [13:28] lol [13:28] Will make sure to always leave a comment [13:28] At least [13:28] sil2100, i do for new sources [13:28] thanks [13:28] a comment would be enogh [13:28] enough [13:28] i look at those [13:30] seb128, so i think that's the cause for the autopkgtest failures for yakkety ppc64el [13:31] Will do, but there's always a comment on top of the packaging diff " * Please consult an archive admin about adding or removing these packages: " for new binaries [13:31] sil2100: yup [13:33] sil2100, seb128: i should have noticed the missing Replaces too... [13:35] kenvandine, also I pointed out that the e-d-s-ubuntu name doesn't make much sense [13:35] even with the description [13:35] is that eds on ubuntu ? for ubuntu ? for ubuntuone? [13:37] yeah, but it matches the eds module name [13:37] but i see your point [13:37] I still don't understand what is "ubuntu" in this contect [13:38] we have -uoa or -goa [13:38] but those are modules for eds to integrate to uoa or goa which are part of ubuntu [13:38] is -ubuntu superseeding -uoa? [13:38] i think these are just for sync [13:38] dunno [13:38] renatu, ^^ [13:38] that landing is a mess :-/ [13:39] kenvandine, sil2100, that upload is blocking in proposed until those issues are sorted, including naming [13:40] seb128, kenvandine , this is an EDS source plugin. To store some ubuntu-phone specific informations into these sources. [13:40] the description should say that [13:40] and the name should be more specific that "ubuntu" [13:40] For example: Every calendar source has the account-id and application-id that creates that source [13:41] seb128, sure I can change that [13:41] seb128, any suggestion :D [13:42] sil2100, did you manualy upload x.org into the xenial overlay? [13:43] bregma: yes, what's up? [13:44] how is that going to work with the ongoing Xmir work and xenial SRUs of the same package? [13:45] was there full testing by the XMir/libertine teams on both device and desktop? (don't bother answering, we didn't get notice) [13:45] bregma: I'll sync that up for a xenial SRU [13:46] bregma: it was a packaging-only change, adding arm64 binaries which did not exist before - testing is not required as there are no testing devices, am I right? [13:46] If there are, why were there no arm64 binaries built? [13:47] The overlay upload was required as we needed this unblocked ASAP, an SRU with the changes will follow [13:48] OK, if you can guarantee it's only a packaging change and it's been coordinated with Ubuntu distro so it doesn't get lost in the SRU process [13:48] given there is no QA on our flagship desktop product and it'd frequently broken by overlay uploads, I am paranoid [13:49] renatu, not really since I don't understand the detail, but e-d-s-utouch-data-sync or similar if that's what it does [13:54] salem_: Back [13:57] salem_: So I have launched messaging app from address book and dialer app [13:58] salem_: "Type message" shows fine, is that the related bottom edge widget? [13:59] rvr, yes, actually, when launched from another app, you don't get the bottom edge [14:00] seb128, is Replaces enough? or do we need a Conflicts too? [14:00] rvr, I mean, if the recipient is set, if you for example launch messaging-app from browser, then the bottom edge must be triggered during startup and the input field populated with the link/text. [14:00] kenvandine, R,B nowadays I think? [14:00] oh right [14:00] Conflicts always confuses me... :) [14:01] salem_: Let me check that [14:11] salem_: oSoMoN: Sharing a link with messaging app shows only the title, not the URL [14:11] (of the page) [14:13] rvr, I think this is a known bug. but a browser bug. [14:24] sil2100, ^ [14:25] \o/ [14:25] mir for arm64 [14:25] eh, autopkgtests are failing for ppc [14:28] sil2100: what's up btw? [14:28] dbarth: ah, unping, nvm - chrisccoulson answered already on -release ;) We had some oxide-related discussion [14:28] sil2100, hm, there is an issue with ubuntu-system-settings and powerd there [14:29] ok nw [14:29] sil2100, unrelated to mir but worth having a look [14:34] seb128, mind taking a look at https://code.launchpad.net/~renatofilho/address-book-service/rename-eds-extension/+merge/300614 [14:35] kenvandine, need to replaces address-book-service (<< 0.1.2) as well no? [14:36] otherwise looks fine [14:36] I'm not sure -utouch is better than -ubuntu [14:36] renatu, ^^ [14:36] seb128, that's what i said :) [14:36] but I'm not going to argue about naming [14:36] it's still not descriptive [14:36] but i don't have any suggestions for something better [14:36] and we are trying to move away from touch [14:36] you can as well keep ubuntu... [14:36] or -ubuntu-source-sync [14:37] that might be long though [14:37] I would prefer not use "sync" [14:37] At least the description should be updated [14:37] it is not specific for sync [14:37] is more to link apps and sources [14:37] well I still not understand what that does [14:37] in case remove a app, we want to remove the sources [14:37] but the name ideally would convey the use [14:38] or the function rather [14:38] whatever that binary once installed doe [14:38] does [14:50] renatu, you need a Replaces for address-book-service as well [14:50] and a Breaks for eds-ubuntu [14:51] kenvandine, Replaces?? with the old version? [14:51] is that not automatically? [14:51] replaces any version [14:52] since that package is going way [14:52] address-book-services does not replaces any package [14:52] no no no [14:52] :D [14:52] +Breaks: address-book-service (<< 0.1.2) [14:52] +Replaces: address-book-service (<< 0.1.2) [14:53] for eds-utouch [14:53] ok [14:53] and add a Breaks: eds-ubuntu too [14:56] seb128, ignore what i said about nautilus-data on ppc64el... that was just because i'm messing around with a schoot with --target ppc64el [14:56] i can't get a qemu image to boot [14:56] to really know wtf is going on === alesage_ is now known as alesage [16:23] https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-036/+build/10493903 has no build log? is this a i386 builder problem? [16:26] kdub: A few builds were taken out by a firewall switchover this afternoon, I believe. I'll dig out the list of build IDs and retry them in bulk. [16:26] cjwatson, ah, alright. thanks! [16:27] Hmm, maybe lcy01 is still sad [16:59] kdub: I've retried the affected builds; the underlying issue isn't yet fixed but I've put the affected builders in manual mode for the time being. [17:00] cjwatson, thanks, so does that mean that if I re-click the build button myself the i386 builds won't work? [17:00] kdub: What? [17:01] cjwatson, not sure what 'manual mode' for a builder is [17:01] and that was my confusing guess [17:01] kdub: Firstly, that build has already succeeded; secondly, it wasn't an i386 vs. everything else issue, it was a subset of the amd64/i386 builders. [17:01] kdub: So for the time being builds will just go to builders that work instead. [17:02] cjwatson, ah, I understand better, thanks for the help [17:02] np === chihchun is now known as chihchun_afk [17:14] ... and they're back now. [17:32] sil2100: unping regarding images, no need to dig, I found a more recent booting xenial image. I'll continue tomorrow pinning down what broke. [17:32] (31 did not boot into unity8, 40 does) [17:33] Mirv: ah! Sorry, saw your ping but forgot to reply - we don't keep too many images in staging for space-efficiency [17:33] I mean, we didn't focus much on staging for now so the fullcount is a bit smaller than usually [17:54] sil2100, as expected we are seeing the same unrelated failure that we had seen with britney during migration in proposed (http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#mir) [17:54] can you help? [17:55] camako: hey! I think kenvandine was looking into that [17:55] camako: you should ask in #ubuntu-release [17:55] yes he was suffering from it too [17:56] robru, ok thanks [17:56] We all are... ;) [17:56] :-) [17:56] I'll be slowly EODing so I would only be able to take a look tomorrow, but possibly someone will resolve that till that time [18:08] Brb [18:19] boiko: This ticket don't have lander not automated signoff https://requests.ci-train.ubuntu.com/#/ticket/1600 :-/ [18:19] doesn't [18:28] camako, sorry i'm about to give up [18:29] can't seem to get a ppc64el environment working enough to try to figure out what depends is broken [18:35] rvr: was approved on the 14th but then rebuilt on the 18th thus invalidating the approval [18:36] robru: I see [18:37] robru: I tested it and wanted to give the seal of approval [18:38] rvr: we should talk to jibel about getting trello cards removed from the queue when lander approval disappears [18:39] robru: Or adding comments [18:39] rvr: really we should roll the trello board into bileto as one unified thing... [18:40] but that's on the backburner for now [18:41] robru: Yeah, that should take some time to develop [18:45] kenvandine, some hint was introduced to get around this problem... Not sure abt the details [18:45] see #ubuntu-release [18:52] camako: it just means the problem is being ignored instead of fixed [18:53] rvr: I think salem_ was testing it [18:53] salem_: did you mark as ready for QA? [18:53] or maybe bfiller did? [18:53] boiko: At some point was marked as ready for QA, because a trello card appeared. [18:54] rvr: yeah, I was not actively testing this one, so it was either bfiller or salem_, let's see what they say about it [18:55] robru, kenvandine: is this still the system-settings issue? [18:55] boiko, can't remember if it was me or bfiller [18:56] salem_: bfiller: but in practice it was already ready for QA, right? [18:56] dobey: on ppc64el, yes [18:58] boiko: the audit log on the ticket says that bfiller approved it on the 14th and then bfiller rebuilt it on the 18th [18:58] still haven't figured that out? seems like an issue in trying to install gnome-settings-daemon and unity-control-center both, afaict [18:58] not sure why it didn't fail on other archs [18:59] dobey, i've been try ing to setup a ppc64el environment to try to reproduce [18:59] tried with the adt tools, qemu, etc [18:59] robru: thanks! [18:59] nothing boots [18:59] boiko: you're welcome [19:00] salem_: you tested the latest version from the silo, right? so I guess we can mark as ready for QA anyways [19:00] kenvandine: i guess a chroot with ppc64el as alternate arch wouldn't work? [19:00] boiko, I did [19:01] dobey, no... i tried that [19:01] it gets really confused :) [19:01] well, make more stuff multi-archable :) [19:01] salem_: bfiller: rvr: I'll mark as ready for QA and then we wait for britney, does that work for you guys? [19:01] boiko: Sure [19:02] boiko, yes [19:05] morphis: Hey. The branch in silo 44 needs review. [19:25] trainguards: Hey, any way to free up some silos? :) [19:25] ChrisTownsend: sure, one sec [19:26] robru: Thanks! [19:27] ChrisTownsend: ok, there's one free for you, I'll free a few others shortly [19:28] robru: k, thanks [19:28] ChrisTownsend: you're welcome [19:35] rvr: salem_: britney approved silo 41 [22:03] boiko: salem_: Silo 41 approved [22:04] rvr, thanks [22:51] rvr: thanks!