[05:03] <Mirv> morning
[05:10] <robru> Mirv: heya. I rolled out some big train changes today, had some hiccups but it mostly seems fine. There's a major performance regression in the publish and merge jobs, it scared me at first but it seems to be working at least. I'll investigate that tomorrow. I'll be up for a couple more hours, please ping me if anything horrible explodes and I'll take a look
[05:17] <Mirv> robru: ok! sounds manageable.
[05:17] <Mirv> robru: ^ a publishing went just fine at least
[05:17] <robru> Mirv: cool
=== chihchun_afk is now known as chihchun
[06:54] <Mirv> robru: I'm getting https://ci-train.ubuntu.com/job/prepare-silo/6125/console after the first assigning failed
[06:54] <Mirv> it's not really assigned
[06:54] <Mirv> not sure if this is a new bug or if it's the first time I forgot first to add the test plan before trying to assign a silo..
[06:55] <Mirv> but it feels like some bit gets incorrectly set ie the check for test plan setting is done too late or the changes are not resetted when it's noticed that a test plan is missing and assigning should be aborted
[06:55] <Mirv> with debug https://ci-train.ubuntu.com/job/prepare-silo/6126/console
[06:58] <Mirv> I left now the https://requests.ci-train.ubuntu.com/#/ticket/332 alone for debugging and created a new request which assigned fine.
[06:59] <Mirv> robru: interesting, the plot thickens. assigning the new silo warned that the package is already in "silo 014" - which is nowhere to be seen. so the 332 assigning-aborting-on-no-testplan really did something half the way.
[06:59] <Mirv> robru: anyway, no worries for the moment, but it's a bit borken at the moment.
[07:56] <robru> Mirv: oh hrm just saw this now
[07:57] <robru> Mirv: can you file a bug? With the debug log
[07:58] <robru> Mirv: there wouldn't be anything "half way" on the Jenkins side, assignment is determined by a single file, so technically the silo assigned. The bug is just that it didn't say the siloname in bileto
[08:00] <robru> Mirv: interesting chicken and egg, the object enforcing those field requirements only loads after the assignment is made. Not sure if i should just suppress the checks at assignment time or perhaps catch the error and delete the assignment file...
[08:04] <Mirv> robru: I'm filing a bug, ok
[08:06] <robru> Mirv: tomorrow I'll focus on bug fixing, too scary to make big changes on a Friday before vacation ;-)
[08:07] <Mirv> robru: ok :) bug #1494628 for your tomorrow then. have a great holiday!
[08:07] <ubot5> bug 1494628 in Bileto "Silo configured "half way" after an error about lack of test plan" [Undecided,New] https://launchpad.net/bugs/1494628
[08:09] <robru> Mirv: thanks
[08:31] <Mirv> jibel: joining?
[08:40] <ogra_> Mirv, i dont think your search includes the right things ... try https://bugs.launchpad.net/canonical-devices-system-image/+bugs?field.tag=hotfix6
[08:44] <Mirv> ogra_: oh! I thought https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1491566 would be on that list but seems not
[08:44] <ubot5> Ubuntu bug 1491566 in Canonical System Image "Shell not responsive after an incoming SMS" [Critical,Confirmed]
[08:44] <nerochiaro> cihelp: hi, any idea why pretty much all the tests fail on this MR when they were successful before ? it could really be a mistake in the code, but they seem to run fine locally: https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/3357/
[08:47] <psivaa> nerochiaro: do you have a link for the passing job for me?
[08:52] <nerochiaro> psivaa: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-vivid-armhf/4041/
[08:53] <Mirv> robru: go. to. sleep. I know you're there!
[08:53] <Mirv> and thanks for the fix :)
[08:53] <robru> Mirv: no I'm not here you're imaginging it
[08:53] <robru> Mirv: you're welcome.
[08:54] <robru> Mirv: it should appear in production in 20 minutes. I tested it in staging so I'm confident nothing will explode.
[08:54] <psivaa> nerochiaro: Isn't a different job, one is running on mako and the other is on a cyclops node?
[08:54] <nerochiaro> psivaa: let me find the link to the right one, sorry
[08:55] <nerochiaro> psivaa: this should be the passing one on mako http://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/3303 sorry for the noise
[08:56] <psivaa> nerochiaro: np, thanks for the link, let me take a look
[09:16] <morphis> Mirv: don't remember well, was there something more to change for a component to get it build with MPs in a silo?
[09:17] <Mirv> morphis: more than what?
[09:18] <morphis> bluez wasn't handled with MPs yet
[09:18] <morphis> I changed that and now ready to use MPs and want to test that with citrain
[09:18] <Mirv> morphis: so the first requirement is that there's an upstream project for it on LP, but Bluez is not developed by Ubuntu or on LP
[09:18] <morphis> so I was just wondering if there is anything more than adding a MP to the request
[09:19] <morphis> Mirv: https://code.launchpad.net/~bluetooth/bluez/vivid-phone-overlay
[09:19] <morphis> that should be the baseline
[09:19] <Mirv> morphis: it seems https://launchpad.net/bluez is registered though
[09:20] <Mirv> morphis: I think that since it's reserved for upstream's usage and not us, we can't take it (and we don't have permissions to do so)
[09:20] <morphis> Mirv: and what is with lp:~bluetooth/bluez/vivid-phone-overlay when I created MPs against that one?
[09:21] <morphis> Mirv: ofono does that similar: see https://requests.ci-train.ubuntu.com/#/ticket/338
[09:21] <Mirv> morphis: we can check what happens if we add ci-train-bot to ~bluetooth
[09:21] <Mirv> morphis: right, sounds good!
[09:21] <Mirv> morphis: so, since you're an admin, please add ci-train-bot to https://launchpad.net/~bluetooth/+members
[09:22] <morphis> dlne
[09:22] <morphis> s/dlne/done/
[09:22] <Mirv> morphis: and then you can try to add  https://code.launchpad.net/~bluetooth/bluez/mer-patches/+merge/270782 to landing
[09:22] <morphis> I need a new silo for that and can't reuse one with a manually upload package, right?
[09:22] <Mirv> morphis: if you also added https://wiki.ubuntu.com/DailyRelease/InlinePackaging .bzr-builddb to it
[09:22] <Mirv> morphis: you can reuse, just remove it from the manual upload packages and add the MP
[09:22] <morphis> ok
[09:23] <morphis> let me try that
[09:25] <morphis> Mirv: ok, looks like I need to get rid of all the quilt patches etc
[09:28] <Mirv> morphis: hmm, right.
[09:44] <psivaa> nerochiaro: so a rerun also is seeing the same failures, i see _usr_bin_webbrowser-app.32011.crash inside the device
[09:44] <psivaa> also _usr_bin_gdb.0.crash
[09:46] <nerochiaro> psivaa: ok, let me investigate that
[09:46] <psivaa> nerochiaro: ack
[10:28] <Mirv> jibel: FYI I've documented a total hang I've experience with OTA-5 and OTA-6 at bug #1494692 now that I got it again
[10:28] <ubot5> bug 1494692 in mir (Ubuntu) "Total hang of the krillin with a graphics artifact" [Undecided,New] https://launchpad.net/bugs/1494692
[10:29] <Mirv> unfortunately not possible to adb in during the hang so not possible to trace any process or such
[11:30] <jibel> Mirv, you cannot even ssh?
[11:31] <Mirv> jibel: so ssh would be enabled by default when developer mode is enabled? that actually counters my trust in using the dev mode, the 4-digit pin-code is not really nice enough if there's a wide open ssh running..
[11:31] <Mirv> (on a personal phone)
[11:32] <davmor2> Mirv: no device has to be unlocked again
[11:33] <Mirv> davmor2: do you mean ssh port is open when the device has screen on / not in lock screen, otherwise closed?
[11:34] <davmor2> Mirv: only works via phablet-shell you have to enable ssh otherwise
[11:34] <davmor2> Mirv: and only over cable
[11:35] <jibel> after I used phablet-shell once and it copied my keys to the phone, I can ssh to the phone locked or unlocked. I don't remember I did anything else.
[11:35] <Mirv> davmor2: right, but that needs adb too?
[11:35] <davmor2> Mirv: no that uses ssh, but should be block the same as adb iirc
[11:36] <Mirv> davmor2: uses ssh, but it requires adb to forward the ssh port in the first place etc?
[11:36] <davmor2> Mirv: so if the screen isn't unlocked there is no connection, I could be wrong on that though
[11:37] <Mirv> hmm, it starts to be a bit too open for my taste to enable that one
[11:37] <jibel> davmor2, you can ssh even with the screen locked, don't you?
[11:37] <jibel> and dev mode on
[11:37] <Mirv> I wonder how it manages it so that the ssh is not available otherwise than via the cable
[11:37] <davmor2> jibel: no
[11:38] <jibel> davmor2, why can I do it then?
[11:38] <davmor2> jibel: did you enable it?
[11:39] <jibel> davmor2, I enabled developer mode and used phablet-shell once.
[11:40] <Mirv> reading https://sturmflut.github.io/ubuntu/touch/2015/05/08/hacking-ubuntu-touch-part-5-adb-shell-vs-phablet-shell/ it'd sound like the ssh still usess an active adb connection for the forwarding
[11:40] <jibel> Mirv, sorry but I'm currently connected to 2 phones over ssh and there is no cable between the laptop and the phones :)
[11:41] <Mirv> jibel: ok, hmm
[11:41] <ogra_> cables are so last century
[11:41] <Mirv> so I guess the adb forward is nothing something that "uses" adb constantly, just sets ports up
[11:41] <davmor2> Mirv: the ssh uses keys
[11:41] <jibel> ogra_, especially on arale which is not recognized on usb
[11:41] <ogra_> yup :)
[11:42] <Mirv> anyway, I'm sure someone else should find the symptoms of my total hangs familiar
[11:42] <Mirv> if no-one else gets them, it might be even a hw fault
[11:43] <jibel> Mirv, after you rebooted is there any interesting event in syslog at the same time than the hang?
[11:43] <ogra_> Mirv, android-gadget-service enable ssh
[11:43] <ogra_> that gives you the non adb ssh
[11:46] <jibel> Mirv, davmor2 phablet-shell enables non adb ssh and copies the ssh key
[11:47] <Mirv> jibel: not really sure... attached syslog snippet from the time to he bug
=== alan_g is now known as alan_g|lunch
[11:59] <Mirv> there are a few things that sound like interesting, but have happened also before the hang and nothing unique during the 12:48 when the hang happened
[12:01] <Mirv> well actually, there is mali_timeline_sync_fence_create() fail!
[12:01] <Mirv> that might be it
[12:13] <Mirv> jibel: thanks, I believe that might be a good indicator here
[12:16] <jibel> Mirv, np, you did all the work.
[12:29] <pmcgowan> what do I need to do to have update to a newer package version from a silo? its not showing as a candidate
[12:29] <pmcgowan> Mirv, ^^
[12:30] <pmcgowan> jibel, ^^
[12:32] <Mirv> pmcgowan: https://wiki.ubuntu.com/LandingTeam/SiloTestingGuidelines#Install_silos_with_overlay_PPA_enabled <- nowadays the instruction there is correct. add a silo.pref file
[12:32] <jibel> pmcgowan, you have to pin the silo higher than the overlay ppa
[12:32] <Mirv> just change the silo number from the example
[12:32] <Mirv> apt upgrade behavior changes immediately after the file is created
[12:32] <jibel> pmcgowan, either use citrain tool but it'll upgrade everything in the silo, if you want to do it manually add something like
[12:33] <jibel> Package: *
[12:33] <jibel> Pin: release o=LP-PPA-ci-train-ppa-service-landing-048
[12:33] <jibel> Pin-Priority: 1002
[12:33] <pmcgowan> thanks guys I knew something changed a while back
[12:33] <jibel> to /etc/apt/preferences.d/extra-ppas.pref
[12:33] <pmcgowan> citrain always fails for me
[12:35] <Mirv> phablet-tools-citrain package version needs to be either from wily or the vivid-overlay (20150519-0ubuntu1)
[12:37] <pmcgowan> Mirv, hmm really? why isnt that package in the sdk tools ppa
[12:37] <pmcgowan> all dev packages should be in sdk-team
[12:38] <pmcgowan> bzoltan, ^^
[12:40] <Mirv> pmcgowan: right, good point. it seems it's there for vivid, but the trusty version is too old.
[12:40] <Mirv> the SDK PPA's vivid version is 15.04.20150722-0ubuntu1
[12:40] <pmcgowan> the vivid version is old as well
[12:40] <Mirv> let's try to building it for trusty tooo
[12:41] <Mirv> it's from July, the pinning was added in May and is visible in its changelog so it does have it
[12:41] <pmcgowan> ok
[12:41] <pmcgowan> but lets keep it in sync, not sure what we have to do but this keeps happening
[12:41] <Mirv> right
[12:41] <pmcgowan> phablet-tools in general not up to date in the ppa
[12:42] <Mirv> we'll update it for vivid+trusty to the latest
[12:44] <Mirv> ok vivid is the latest (same contents as wily, newer date). trying to compile for trusty.
[12:46] <Mirv> bzoltan: I uploaded 1.1+15.10.20150519-0ubuntu1~trusty1 to https://launchpad.net/~ubuntu-sdk-team/+archive/ubuntu/testing/ - let's copy SDK Release PPA after testing it for a while (made an AP for myself)
=== alan_g|lunch is now known as alan_g
[13:41] <bzoltan> Mirv: pmcgowan:  it is about staging those packages... I am testing those packages and usually I wait for big landings to test the whole chain before copying over. We were burned so many times by these tools.
[13:42] <bzoltan> pmcgowan :  Mirv: the phablet tools are build from their trunk by a recipe in the Dev Tools PPA
[13:44] <pmcgowan> bzoltan, what do we need to do to ensure sdk ppa always has latest phablet tools
[13:48] <bzoltan> pmcgowan: If you want to to an automatic landing of the phablet-tools on each and every developers machine whenever the lp:phablet-tools trunk is updated then it should have a test plan and it should be tested from a landing silo and/or a staging repository just as any other component what is landed.
[13:48] <bzoltan> pmcgowan: Without it there will be a sometimes not so comfortable gap between the lp:phablet-tools trunk and the SDK PPA
[13:49] <pmcgowan> bzoltan, I just want it fixed of course
[13:50] <bzoltan> pmcgowan: everybody wants quick release ... but when a non tested component burns developers then we suffer.
[13:50] <pmcgowan> bzoltan, so i agree, lets control it but lets actually get the update
[13:52] <bzoltan> pmcgowan: +1 i am checking the lp project and the staging ppa right now
[13:52] <Laney> Mirv: how do I train something to the overlay ppa that is already in wily?
[13:53] <Laney> an empty commit or something?
[13:54] <bzoltan> Mirv: where the phablet-tools is coming from actually? I see this https://code.launchpad.net/~phablet-team/phablet-tools/trunk no recent update
[14:44] <Laney> can I use sync source for this?
[14:46]  * Laney is bold
[14:46] <anpok> cihelp: is our mir ci job mir-clang-vivid-amd64 using the stable-phone overlay?
[14:47]  * Laney got it wrong
[14:50] <fginther> anpok, no, it does not
[14:50] <Laney> ok I don't know how to do this :)
[14:50] <Laney> robru: he;lp
[14:50] <anpok> fginther: i just realized that also mir-mediumtests-builder-vivid-armhf needs the ppa to successfully build
[14:51] <anpok> https://code.launchpad.net/~andreas-pokorny/mir/libinput-platform/+merge/270313 this is the MP I am trying to get built
[14:51] <anpok> which relies on a libinput version only in vivid+overlay
[14:52] <anpok> hm maybe I should try getting it through a SRU?
[14:54] <Mirv> bzoltan: there's no development since May, it's the correct trunk
[14:55] <fginther> anpok, that might be best. In the past, I thought the goal was to keep mir buildable w/o the overlay PPA, but I could be wrong. This is entirely up to the mir team.
[14:57] <Mirv> Laney: either a new no-op dual landing or a vivid only landing with the sync-from-wily feature (examples in wiki)
[14:57] <Mirv> no-op eg an empty MP
[14:58] <Laney> Mirv: I'm trying to sync
[14:58] <anpok> fginther: I will discuss in a few minutes.. I thought since we are currently targeting vivid+overlay and wily adding the PPA is the right way to go.
[14:58] <Mirv> bzoltan: trusty phablet-tools hadn't been updated for ages, I think that was the only omission
[14:58] <Laney> but I got a KeyError, help meeeeeeeeeeeeeeeeeeeeeeeeeeeee :)
[14:58] <Laney> https://requests.ci-train.ubuntu.com/#/ticket/344
[14:59] <Laney> there are two normal uploads (dput, already there) and one which could be synced
[14:59] <Laney> that's lxc-android-config
[15:04] <Mirv> Laney: sorry, I'm off already and doing this on my Bq and it seems our Bileto is not very optimized yet for our browser. please check the syntax from wiki, sync:ubuntu,wily lxc-android-config or some such
[15:04]  * Mirv goes back to eating pizza
[15:04] <Laney> Mirv: ok I'm waiting for someone else
[15:04] <Mirv> robert should be here in 1h or so
[15:05] <Laney> I think I used the syntax the wiki says
[15:05] <Laney> but I don't know if it supports only syncing some things
[15:05] <Laney> enjoy pizza
[15:05] <Mirv> robru: bileto should work on Ubuntu phone :)
[15:16] <balloons_> ping cihelp. Can I get utopic jobs disabled on ubuntu-docviewer-app-reboot-ci and ubuntu-docviewer-app-reboot-ci-autolanding?
[15:24] <josepht> balloons_: I'll take care of that for you
[15:43] <anpok> fginther: ok discussed with mir team - we only target vivid+overlay and wily
[15:43] <anpok> so we want those jobs to include the stable phone ppa
[15:44] <fginther> anpok, will do. Should have this finished today.
[15:44] <fginther> anpok, do you have an MP that depends on this work?
[15:45] <anpok> yes
[15:45] <anpok> https://code.launchpad.net/~andreas-pokorny/mir/libinput-platform/+merge/270313
[15:50] <robru> Laney: "sync:" is spreadsheet talk, you don't need to specify "sync:" in the sync field, it's redundant.
[15:50] <robru> Laney: does the wiki still say to put in "sync:"? I thought i got rid of that
[15:50] <Laney> robru: https://wiki.ubuntu.com/citrain/LandingProcess#Syncing_from_and_to_the_Stable_Overlay_PPA
[15:53] <robru> Laney: fixed, try building.
[15:53] <Laney> robru: can I say to just sync one thing?
[15:53] <Laney> like if I put it in the packages to rebuild field
[15:54] <robru> Laney: yes, "PACKAGES_TO_REBUILD" is a misnomer, it means "act upon only these packages"
[15:54] <Laney> I guess it existed before syncs were a thing
[15:54] <robru> yes
[15:55] <Laney> alright, this seems to be doing thing which is good thing
[15:55] <Laney> thanks!
[15:55] <robru> Laney: you're welcome
[15:56] <Laney> hm
[15:56] <Laney> it didn't use a different version
[15:56] <Laney> oh no lies
[16:00] <josepht> balloons_: this is done!
[16:00]  * balloons_ looks
[16:01] <balloons_> k, trying a build to check
=== balloons_ is now known as balloons
[16:53] <robru> kenvandine: hey, you around?
[16:53] <kenvandine> robru, yeah, what's up?
[16:54] <robru> kenvandine: can you run this job for me? https://ci-train.staging.ubuntu.com/job/ubuntu-landing-004-2-publish/parambuild/?IGNORE_VERSIONDESTINATION=true&DEBUG=true&ACK_PACKAGING=true (don't worry, staging area doesn't have permission to do anything)
[16:54] <robru> I'm debugging some train stuff
[16:54] <kenvandine> ok
[16:54] <kenvandine> 404 error
[16:55] <robru> kenvandine: ugh, sorry, log in & then go to the link
[16:55] <robru> kenvandine: log in at https://ci-train.staging.ubuntu.com
[16:55] <robru> kenvandine: and make sure your teams are checked
[16:56] <robru> it won't 404 after you log in
[16:56] <kenvandine> https://ci-train.staging.ubuntu.com/job/ubuntu-landing-004-2-publish/6/console
[16:57] <robru> thanks!
[16:57] <kenvandine> np
[17:02] <robru> ok, I gotta run to the doctor, should be back in 2 hours or so!
[18:24] <robru> kenvandine: can I get a packaging ACK? https://ci-train.ubuntu.com/job/ubuntu-landing-029-2-publish/42/ (and if you do publish, please enable DEBUG)
[18:25] <Trevinho> robru: what's up with AP legacy?
[18:25] <robru> Trevinho: I tried to publish your silo but I can't because there's packaging changes
[18:25] <Trevinho> robru: mh, I just applied a patch that in debian/patches with no sense right now...
[18:26] <Trevinho> I could even put it back where it was, but I don't see the reasen
[18:26] <Trevinho> reason*
[18:26] <robru> Trevinho: do you or do you not want your silo published right now?
[18:26]  * kenvandine is looking at it
[18:26] <Trevinho> robru: well, if we can...
[18:27] <Trevinho> kenvandine: thanks
[18:27] <robru> Trevinho: ok but did you just say you were still working on it? Because "Publish without QA" means "publish now"
[18:27] <Trevinho> robru: no, I wansn't working on it.. it was ready to publish to me
[18:27] <Trevinho> robru: in case you need it to be changed, I could, but I'd prefer not
[18:28] <robru> Trevinho: well ken has the right to refuse your packaging if he finds a mistake. but I don't personally care.
[18:28] <Trevinho> I see... I've noticed the debian changelog entry for the patch is wrong though
[18:29] <robru> Trevinho: I didn't really understand what you said about applying a patch that doesn't make sense. so the silo in it's current state has a patch that doesn't make sense, but isn't worth removing?
[18:29] <robru> that seems like a weird thing to want to publish
[18:29] <Trevinho> robru: no, maybe I've not been clear. there was a debian/patch that it didn't make sense to be there as downstream patch. So I've just applied it upstream.
[18:30] <robru> Trevinho: oh, well that's good then
[18:30] <kenvandine> it's fine
[18:30] <robru> Trevinho: thanks for clarifying
[18:30] <Trevinho> yeah, sorry... I thought it was clear by diffs but maybe not :)
[18:30] <robru> kenvandine: please publish with DEBUG, I need DEBUG on to profile the performance of the job
[18:31] <kenvandine> done with debug :)
[18:31] <Trevinho> yay
[18:32] <robru> kenvandine: thanks
[18:32] <kenvandine> 2015-09-11 18:32:36,303 ERROR https://code.launchpad.net/~3v1n0/autopilot/badwindow-errors-protect-legacy/+merge/268995
[18:32] <kenvandine> 2015-09-11 18:32:36,304 ERROR Some merges have unbuilt revisions.
[18:32] <kenvandine> ugh
[18:33] <kenvandine> Trevinho, silo needs a rebuild
[18:33] <Trevinho> ouch
[18:33] <Trevinho> I thought I had
[18:33] <kenvandine> make sure you list autopilot in the list of packages to rebuild
[18:33] <kenvandine> that's the only one that needs a rebuild
[18:34] <Trevinho> yeah, I've done that... I thought I had done this morning even, but maybe I added something else. :/
[18:34] <robru> bah
[18:34] <kenvandine> give me a shout when it needs to be published
[18:35] <Trevinho> k, thanks
[18:35] <robru> kenvandine: due to the publish failure I didn't get the info I needed from that debug log, please also set DEBUG next time you publish too
[18:36] <kenvandine> robru, will do
[18:36] <robru> kenvandine: thanks
[18:36] <Trevinho> kenvandine: ah... might that be because the approved revision is an old one?
[18:37] <kenvandine> i don't think so
[18:37] <kenvandine> looks like the revision built in the silo doesn't match the latest in that one branch
[18:38] <Trevinho> ok, ok.. that's fine.. It's rebuilding now, it should take few minutes
[18:54] <Trevinho> kenvandine: ^
[18:55] <kenvandine> publishing with debug https://ci-train.ubuntu.com/job/ubuntu-landing-029-2-publish/44/console
[18:55] <kenvandine> robru, ^^
[18:55] <robru> kenvandine: thanks a bunch
[18:59] <kenvandine> np
[20:06] <oSoMoN> trainguards: hey, I need help with silo 35, the train refuses to do a source copy from https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/ppa/+packages because of the custom version, can you do a manual source copy?
[20:06] <oSoMoN> (detailed failure: https://ci-train.ubuntu.com/job/ubuntu-landing-035-1-build/48/console)
[20:06] <robru> oSoMoN: sure one sec
[20:06] <robru> oSoMoN: wait, you want a source copy? not a binary copy?
[20:07] <oSoMoN> robru, yes, because oxide-qt links against libmedia-hub, and there are ABI changes in the version in the overlay PPA
[20:07] <robru> oSoMoN: good to know
[20:08] <robru> oSoMoN: just to confirm you want 1.9.2-0ubuntu0.15.04.1 copied?
[20:08] <robru> of oxide-qt
[20:08] <oSoMoN> robru, correct
[20:08] <robru> ok
[20:09] <oSoMoN> I don’t mind if the train adds a custom suffix to the version number
[20:09] <robru> oSoMoN: manual PPA copy like this won't change the version number.
[20:09] <oSoMoN> ok, even better then :)
[20:09] <robru> oSoMoN: please change your request to a manual source (drop the sync request) and do a WATCH_ONLY build.
[20:10] <oSoMoN> launched: https://ci-train.ubuntu.com/job/ubuntu-landing-035-1-build/49/console
[20:11] <robru> oSoMoN: great, thanks.
[20:14] <oSoMoN> robru, thanks for your help
[20:14] <robru> oSoMoN: you're welcome
[20:15] <jdstrand> oSoMoN: I'm not sure it is even better-- having two differently built and linked packages with the same version number may be an issue long term. not saying we should block this upload, but food for thought
[20:41] <robru> jdstrand: "it's just the overlay PPA". this rebuilt thing won't be in ubuntu archive.
[20:41] <jdstrand> sure
[20:41] <robru> jdstrand: but generally I agree with the premise that two different builds with same version number is bad.
[20:42] <jdstrand> it just adds an additional qualifying question
[20:42] <jdstrand> "what version are you running? oh, and on what system?"
[20:42] <jdstrand> anyway, not trying to block, just stating a preference
[20:42] <robru> jdstrand: well, apt-cache policy will show where it's from, which will answer the question as well
[20:43] <jdstrand> maybe-- that would depend on the ordering of sources.list if -security and the overlay were enabled in sources.list
[20:51] <robru> jdstrand: yes, overlay ppa shows up in sources.list on the phones. it's also pinned higher than everything else, so policy reports that that's where packages come from
[20:59] <oSoMoN> jdstrand, good point