=== daker_ is now known as daker
=== slangase` is now known as slangasek
=== infinity1 is now known as infinity
=== kalikiana_ is now known as kalikiana
=== vrruiz_ is now known as rvr
[09:20] <seb128> shrug
[09:20] <seb128> who published libusermetrics?
[09:21] <seb128> was that me?
[09:21]  * sil2100 didn't push any buttons right now
[09:21] <seb128> I guess I pressed the button on the wrong line :-/
[09:22] <seb128> shrug
[09:22] <sil2100> I noticed it can get confusing... was it not ready for publishing?
[09:22] <seb128> it was failed QA
[09:23] <seb128> it creates some minor issue
[09:24] <sil2100> seb128: do you have the power to drop it from -proposed?
[09:24] <sil2100> I could re-upload the ealier version to the overlay
[09:24] <sil2100> And then restore the landing request
[09:24] <seb128> yes, but I wonder if we should keep it and fix the remaining issue
[09:24] <sil2100> jibel, davmor2: ^ hey, what do you guys think?
[09:25] <jibel> seb128, what is the issue it introduces?
[09:25] <seb128> the update was meant to hide the "no data source"
[09:25] <seb128> by settings the message to ""
[09:25] <sil2100> Can we just leave the slightly broken libusermetrics in our images for now?
[09:25] <seb128> but unity8 hides the infographics in this case
[09:25] <jibel> seb128, when can you land an update?
[09:25] <seb128> unsure, need to check with mterry/mpt what would be the right fix
[09:26] <seb128> but today or tomorrow I guess
[09:26] <seb128> (assuming that unity8 is fine to land if needed)
[09:26] <seb128> jibel, the change is going to make the infographic "circle" not show on first boot devices, they would just have the bg image and the date, etc
[09:26] <seb128> as soon as the user loged in the infographics is there though
[09:27] <seb128> it's just replace the "no data source" case by "hide the infographics"
[09:27] <seb128> the fix would be to not hide it, just have it there with no message
[09:27] <jibel> sil2100, maybe you can just announce the known issue introduced by this change in your landing email and just move on as long as the right fix lands this week
[09:28] <sil2100> +1
[09:28] <seb128> thanks
[09:28] <jibel> seb128, if you think the fix cannot land today or tomorrow, tell sil2100 and he'll revert the package before next build
[09:28] <seb128> right
[09:30] <jibel> robru must fix the UI, you are not the first pressing the wrong buttons
[09:32] <sil2100> I still think my proposition with 'click to show details (and controls)' is a better idea than the hovering buttons ;)
[09:33] <sil2100> It would make the UI much more user and eye friendly I think
[09:37] <seb128> also I had set the verification to "QA failed"
[09:37] <seb128> the system should refuse to publish something which is QA failed
[09:37] <seb128> or at least request an override
[09:41] <jibel> seb128, I filed bug 1496326
[09:41] <ubot5> bug 1496326 in Bileto "User can publish silos set to 'QA Failed'" [Undecided,New] https://launchpad.net/bugs/1496326
[09:42] <sil2100> jibel: good point - in the times of the spreadsheet it was impossible to do, as the train had no understanding of the spreadsheet
[09:42] <sil2100> But now it makes perfect sense to add that
[10:17] <bzoltan> sil2100: might not be your desk, but do you know how to kick Jenkins to pick up an MR? I would like to include the updatet UITK test plan with this - https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/silo_pinning/+merge/271235 but J ignores it
[10:20] <sil2100> bzoltan: hm, did you have jenkins CI enabled for the lp:ubuntu-ui-toolkit/staging merges?
[10:20] <sil2100> bzoltan: but just to be certain I would poke cihelp, they would know more probably
[10:21] <bzoltan> sil2100:  that staging branch is our development focus... loads of MRs land on in automatically after reviews and Jenkins tests
[10:30] <sil2100> bzoltan: strange indeed, it seems the branch didn't trigger anything on the s-jenkins side
[10:30] <bzoltan> sil2100:  I can delete the whol branch/MR and try again
[10:30] <sil2100> bzoltan: I can trigger it manually for you, but cihelp would have to be pinged anyway to see what happened and why
[10:31] <sil2100> ogra_: hey hey! Do you have a moment to review my noobish seed-addition MP? https://code.launchpad.net/~sil2100/ubuntu-seeds/ubuntu-touch.wily-add_pd/+merge/271272
[10:32] <sil2100> bzoltan: want me to trigger manually?
[10:33] <psivaa> sil2100: let me check on that mP
[10:34] <sil2100> psivaa: thanks :)
[10:34] <bzoltan> sil2100:  that would be great if you can do that
=== zbenjamin_ is now known as zbenjamin
[10:35] <sil2100> bzoltan: psivaa is on it, let's see if he can find anything ;)
[10:35] <bzoltan> sil2100: psivaa: super! Thank you
[10:40] <sil2100> ogra_: aaand, if you have time and like doing seed reviews (;p), here's another one: https://code.launchpad.net/~sil2100/ubuntu-seeds/ubuntu-touch.wily-pulseaudio-trust/+merge/268381
[10:49] <bzoltan> sil2100: Mirv: hmmm... what do I do wrong?  I can not assign silo to this https://requests.ci-train.ubuntu.com/#/ticket/368
[10:54] <psivaa> sil2100: bzoltan: https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/silo_pinning/+merge/271235 is now awaiting jenkins review
[10:55] <psivaa> I did not do anything, it must have been waiting in the queue
[10:57] <Mirv> bzoltan: some sort of train wreck there
[10:59] <bzoltan> psivaa: thank you
[10:59] <pstolowski> rvr, hi! any chance to get silos 59 and 35 verified quickly? these are just small api enhancements and we need these to proceed with actual feature landings, only check that makes sense right now is to ensure no regressions
[11:01] <Mirv> hmmh, now it says no silos
[11:02] <Mirv> sil2100: we'd need a direct view to the assigned silos as a backup, bileto sometimes hides the fact that a silo is assigned while the line claims there's no silo
[11:03] <Mirv> sil2100: now 368 claims it's already assigned while it's not. I once fixed such a problem by copying the line, assigning the new line, checking the jenkins job which said what silo the new line is conflicting it, and manually freed up the silo. but now I can't even assign the new line https://ci-train.ubuntu.com/job/prepare-silo/6167/console
[11:03] <rvr> pstolowski: 35 is on the top of the queue, we have other silos to do as well
[11:03] <pstolowski> trainguards hey, only_free_silo fails for me with silo 38
[11:04] <Mirv> ok, I found up what it meta-assigned https://ci-train.ubuntu.com/job/prepare-silo/6162/console
[11:04] <pstolowski> trainguards, ah, nvm, fixed that
[11:04] <pstolowski> rvr, ack, thanks
[11:04] <Mirv> pstolowski: yeah seems so
[11:05] <Mirv> wtf
[11:05] <Mirv> b"Object: <Branch u'~stolowski/unity-scope-mediascanner/audio-card' (16939779)>, name: u'267325'"
[11:05] <pstolowski> Mirv, bileto seems to be a bit picky even about stuff that doesn't matter anymore, e.g. only_free_silo failed becuse qa_signoff wasn't set for this silo
[11:05] <Mirv> when assigning _bzoltan's_ silo
[11:06] <Mirv> pstolowski: yeah, there are small things, but there are also these big problems I'm more worried about :)
[11:06] <pstolowski> Mirv, fair enough
[11:06] <Mirv> pstolowski: do you have any idea abou that above? ^ is it a typo you've done somewhere on some line at some point?
[11:07] <pstolowski> Mirv, checking
[11:07] <Mirv> actually, https://code.launchpad.net/~stolowski/unity-scope-mediascanner/audio-card does exist
[11:08] <Mirv> weird stuff. but I wonder if it's related to the fact Launchpad is somehow stalled otherwise too, eg diff:s and branches don't update
[11:08] <pstolowski> Mirv, yes, just fixed that, sorry, I were doing some cleanups this morning and messed that up
[11:09] <Mirv> pstolowski: what did you break, and where? I mean, I'm just trying to understand how you messing up something could affect prepare-silo for completely another landing..
[11:11] <Mirv> pstolowski: whatever you did, thanks for fixing it, now I was able to assign bzoltan a silo :D
[11:11] <Mirv> pstolowski: but please tell us what you did, we need Bileto to not break on it :)
[11:12] <Mirv> bzoltan: ^ silo 038
[11:12] <pstolowski> Mirv, i re-targeted some MPs for unity-scope-mediascanner, and also removed trunk-15.04 from unity-scope-mediascanner project; this removed two MPs that depended on it in LP (and apparently I forgot to update MPs in bileto or didn't save after updating)
[11:13] <bzoltan> Mirv: \o/
[11:13] <Mirv> pstolowski: ok... I wonder how on earth that could break prepare-silo for another landing. thanks!
[11:14] <pstolowski> Mirv, yw :)
[11:14] <Mirv> sil2100: so just FYI, apparently having a 404 MP in some landing could somehow magically break all the next prepare-silo runs for any line
[11:15] <sil2100> Mirv: huh?
[11:15] <Mirv> sil2100: in other news, somehow we're out of 60 silos when the counter says "57"
[11:15] <Mirv> sil2100: this is assigning an UITK landing silo https://ci-train.ubuntu.com/job/prepare-silo/6162/console - check the response body
[11:17] <sil2100> I suppose the train got confused and assigned some silos that it shouldn't have
[11:19] <Mirv> yeah, that happens every time there's some error in prepare-silo that's not early
[11:19] <Mirv> now it'd be nice to know what those silos are
[11:23] <cjwatson> Mirv: it's what now?
[11:24] <cjwatson> Mirv: which diffs/branches exactly?
[11:25] <Mirv> cjwatson: https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/silo_pinning/+merge/271235 - the MP + the branch
[11:27] <Mirv> just the web frontend though, I can bzr branch normally
[11:27] <cjwatson> Mirv: scanning large branches is slow and sometimes times out.  the remedy is, if it hasn't scanned after six minutes, a branch or project owner should use http://paste.ubuntu.com/12426030/ as "lp-rescan-branch lp:~bzoltan/ubuntu-ui-toolkit/silo_pinning"
[11:28] <Mirv> sil2100: ^ you might want to save that script too
[11:28] <cjwatson> Mirv: (the other remedy is to use git, but the train doesn't support that yet ...)
[11:29] <cjwatson> Mirv: the unity-scope-mediascanner error you mentioned above seems to be that the MP URL is out of date
[11:29] <cjwatson> from https://code.launchpad.net/~stolowski/unity-scope-mediascanner/audio-card, the ID should be 271251, not 267325
[11:30] <cjwatson> ah, but pstolowski updated that
[11:30] <Mirv> cjwatson: sil2100: it seems I could run the script and it fixed the diff even though I'm not the branch owner
[11:31] <Mirv> cjwatson: that's fine, getting 404, the problem is getting the error on a completely unrelated operation on a different landing. somehow bileto digged up pstolowski's MP when trying to assign a silo for bzoltan's MP:s.
[11:31] <cjwatson> Mirv: you're a project owner, well, driver, anyway
[11:31] <cjwatson> Mirv: yeah, that's totally unrelated to the ubuntu-ui-toolkit scan failure
[11:31] <Mirv> cjwatson: ok, then it often will work for us
[11:31]  * sil2100 saves the script
[11:32] <sil2100> Mirv: could you fill in a bug about the 404 to cupstream2distro?
[11:33] <Mirv> cjwatson: that too, but also unrelated to ubuntu-ui-toolkit landing line assigning attempt
[11:33] <pstolowski> i'm innocent
[11:33] <Mirv> sil2100: doing
[11:33]  * pstolowski hides
[11:33] <Mirv> pstolowski: yes, you are :)
[11:33]  * sil2100 includes the script in his lt-tools
[11:33] <sil2100> Mirv: thanks!
[11:33]  * Mirv included it in his ever growing "helpers" dir which is in PATH
=== alan_g is now known as alan_g|lunch
[12:01] <seb128> jibel, thanks
[12:41] <pstolowski> rvr, hey, please forget about silo 59 for now, i need to rethink landing strategy for it...
[12:44] <jibel> pstolowski, you mean it is not ready for qa anymore and you'll resubmit it?
[12:45] <pstolowski> jibel, yes
[12:45] <rvr> pstolowski: Ok
=== alan_g|lunch is now known as alan_g
=== sil2100_ is now known as sil2100
[13:20] <davmor2> popey: weather app is it just gui changes or are there any backend changes too?
[13:21] <popey> davmor2: its a rewrite really
[13:21] <popey> a few bits re-used, but pretty much mostly new
[13:21] <davmor2> popey: ah okay
[13:21] <davmor2> popey: thanks that would explain the lack of changelog if it is new :)
[13:22] <popey> heh yeah
[13:22] <popey> Changelog: Everything
[13:31] <pete-woods> trainguards: hi folks. I'd like to convert my dual landing silo to a vivid only one (https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-039)
[13:32] <pete-woods> could you folks be so kind as to just nuke all the builds from it?
[13:32] <pete-woods> (or I end up with version number errors)
[13:33] <sil2100> uuuuh, ok, this will require a silo re-assignment
[13:34] <sil2100> e.g. we need a different silo for it
[13:34] <sil2100> hm, ah, no, wait
[13:34] <sil2100> From dual to vivid, ok
[13:35] <sil2100> pete-woods: ok, let me reconfigure it for vivid-overlay only and remove the wily packages
[13:36] <pete-woods> sil2100: could you remove the vivid ones too?
[13:36] <pete-woods> or I guess I can just bump the "real" version number
[13:36] <sil2100> pete-woods: sure, although CI Train will anyway have to auto-bump the version numbers itself
[13:36] <sil2100> I think the train should deal with it by itself
[13:37] <pete-woods> I don't think it will
[13:37] <pete-woods> it will try and release realversion+15.04-xxxx
[13:37] <pete-woods> instead of realversion+15.10-xxxx
[13:37] <sil2100> At least, in principle it does that, but the code changed so much that I'm not sure anymore - since when the train re-builds packages, it changes the version to date.iterator
[13:37] <sil2100> Well, when dual landings are made, the versions are changed
[13:38] <pete-woods> at any rate, can fix by a manual bump of the real version :)
[13:38] <sil2100> So if you have version realversion+15.10-xxxx in a dual landing, the train prepares the vivid part as realversion+15.04-xxxx anyway
[13:38] <pete-woods> oh, right
[13:38] <pete-woods> hmm
[13:38] <sil2100> And if it already sees some realversion+15.04-xxxx version, it should change it to realversion+15.04-xxxx.1
[13:38] <pete-woods> wonder why I got that build error then
[13:38] <pete-woods> never mind
[13:38] <pete-woods> will see what happens
[13:38] <sil2100> Let's try anyway ;)
[13:38] <sil2100> YEah
[13:39] <sil2100> pete-woods: remember to add the target ppa overlay!
[13:39] <sil2100> pete-woods: let me fix that for you
[13:39] <pete-woods> sil2100: oh, er, is that a new thing?
[13:40] <pete-woods> okay, I see it
[13:40] <sil2100> pete-woods: reconfiguring now
[13:40] <sil2100> Ah, forgot that reconfigures are not needed anymore
[13:41] <sil2100> Anyway, fixed - if you don't specify the overlay target, the silo targets main vivid
[13:41] <pete-woods> that's good to know
[13:41] <pete-woods> this is what happens when you're away for a while :)
[13:44] <pete-woods> sil2100: oh actually while you're about. I was hoping you'd be able to upload the vmware xorg driver to the overlay PPA
[13:44] <sil2100> pete-woods: oh, sure thing - it got the same fix as the others?
[13:44] <pete-woods> as otherwise anyone using vmware (like me a some others) and the overlay PPA get borked X11
[13:45] <pete-woods> sil2100: I have no idea of the technical details exactly, but I can see intel, amd and nvidia drivers in there
[13:45] <pete-woods> and figured an upload for vmware would help me out
[13:47] <sil2100> Sure thing
[13:47] <sil2100> Let me find it and upload
[13:52] <sil2100> pete-woods: do you know which version is required? Is 1:13.1.0-2ubuntu1 what's needed, or the previous no-change rebuild is enough?
[13:52] <sil2100> As I don't know the details of the vmware problems as well
[13:53] <pete-woods> sil2100: all I know is a get a black screen if I allow xorg to be updated
[13:53] <pete-woods> sil2100: I'm happy to try random debs if you can get them to me, though :)
[13:54] <sil2100> hm, ok, let me try that then, I'll poke you a bit later ;)
[14:02] <sil2100> grrr, there's a bug in the new publisher
[14:04] <sil2100> kenvandine: hey! Could you press the publish button on https://ci-train.ubuntu.com/job/ubuntu-landing-035-2-publish/ ? There's no packaging changes and the packages are in universe, but the train doesn't notice that and says I have no permissions
[14:04] <sil2100> kenvandine: most probably because the dual landing creates a manual source upload for the second package
[14:11] <sil2100> kenvandine: ok, found the bug
[14:12] <kenvandine> sil2100, ?  do you need me to publish it?
[14:12] <kenvandine> i was about to :)
[14:12] <sil2100> kenvandine: yes, please :)
[14:12] <sil2100> I need to fix it in the train
[14:12] <kgunn> robru: you know what would be cool if one could search bileto and include something like "-Landed" in the search string to filter out things you don't want to see
[14:12] <kgunn> afraid you might tell me there's already a way to do this :)
[14:12] <sil2100> robru's approach is more or less correct, but misses the case that by default *all* PPA packages have component = main
[14:13] <sil2100> For PPAs the check shouldn't even be enforced
[14:13] <sil2100> Maybe just checking permissions if the user is able to copy packages to the PPA
[14:13] <kenvandine> sil2100, it does need packaging ack
[14:14] <sil2100> kenvandine: oh, it does?
[14:14] <kenvandine> https://ci-train.ubuntu.com/job/ubuntu-landing-035-2-publish/24/artifact/mediascanner2_packaging_changes.diff
[14:14] <sil2100> Ok, thought that the ACK phase is before the authorization phase
[14:14] <kenvandine> it should be
[14:14] <kenvandine> imo
[14:15] <kenvandine> so we know to get a packaging review
[15:00] <Saviq> cihelp, hey, there's a few tweaks we'd need done to some of the unity8/unity-api/qtmir -ci jobs, let me know please if you can help
[15:03] <fginther> Saviq, what's up?
[15:07] <robru> sil2100: kenvandine ack and authorization phases are intertwined, because it needs to fail only if you're both unauthorized and there's a diff. Can't separate them
[15:08] <robru> Mirv: i have a branch overhauling prepare but I'm not ready to go to production until after i get back next week
[15:08] <Saviq> fginther, hey, we're resyncing wily and vivid branches on those three projects
[15:09] <Saviq> fginther, so we'd need ci to run for both wily and vivid+o on their trunks
[15:09] <Saviq> fginther, it's fine with us if the two instances "fight" on the vote (they both should be green after all anyway)
[15:10] <Saviq> fginther, could this work?
[15:10] <robru> Mirv: sil2100: nothing magical or mysterious about that prepare bug, the log clearly says it's checking other silos for conflicts when it explodes on that MP being wrong. Wouldn't have happened before because all the silo configs were cached but now it has to scan them all live every time
[15:12] <sil2100> robru: https://code.launchpad.net/~sil2100/cupstream2distro/fix_ppa_publish/+merge/271326 <- something I prepared quickly inbetween stuff if anything
[15:12] <sil2100> But don't bother reviewing it now, you're on holidays ;)
[15:12] <sil2100> It's not anything urgent
[15:13] <bzoltan> sil2100:  I have captured this beauty on the wily UITK build -> http://pastebin.ubuntu.com/12427360/ could it be a gcc5 effect?
[15:13] <robru> sil2100: no that coffee will fail as is
[15:13] <robru> Code
[15:14] <sil2100> Oh, why?
[15:14] <robru> sil2100: that's how i originally wrote it, checkUpload doesn't work like you expect on PPAs because they don't have proposed pockets
[15:15] <sil2100> Ah, right, when I tested it I actually had pocket='Release'
[15:15] <sil2100> Ok, we need to make it aware of PPAs then
[15:15] <robru> sil2100: i raised this with slangasek and we decided it made more sense to enforce same archive permissions on overlay PPA rather than check PPA permissions
[15:15] <sil2100> robru: but this way it just fails miserably
[15:16] <sil2100> For instance I have universe powers but can't publish any universe package to the overlay
[15:16] <sil2100> Ok, anyway, I'll find a way to do that
[15:17] <fginther> Saviq, the jobs can be configured to run both wily and vivid+overlay builds for a single MP
[15:17] <Saviq> fginther, great
[15:17] <fginther> Saviq, would that work?
[15:18] <robru> sil2100: I'm not sure why... If you have universe power and checkUpload fails then i guess there's a bug in your universe powers
[15:18] <Saviq> fginther, didn't know that was possible, but yeah, that's even better
[15:18] <cjwatson> sil2100,robru: I suspect the problem is that it's using sourcepub[0].component_name
[15:18] <sil2100> robru: no
[15:18] <cjwatson> which will be the publication in the PPA, and hence component_name will be main
[15:18] <sil2100> robru: since when you poke for getPublishedSources from the PPA, all sources have by default 'main' component
[15:18] <cjwatson> it's going to need to do a getPublishedSources on main_archive or something like that
[15:18] <Saviq> fginther, that's lp:unity8, lp:unity-api and lp:qtmir, the -wily job for unity8 could be dropped then
[15:18] <sil2100> robru: so then you check if I have powers to upload 'main' packages on the main archive and it fails
[15:19] <cjwatson> so actually, the bug may just be that checkupload_phase does self.dest.getPublishedSources rather than self.main_archive.getPublishedSources
[15:19] <sil2100> cjwatson: true, that could be a potential solution
[15:19] <sil2100> Although I would prefer to check the destination ppa checkUpload
[15:19] <sil2100> To make sure that the given user has permissions to push that to the PPA
[15:20] <cjwatson> well, if we're trying to enforce same archive permissions as the main archive as robru says above, then it needs to be main_archive.  But that's a requirements issue
[15:20] <sil2100> cjwatson: checkUpload() checks not only the component-upload permissions, but checks also if the user has write access in the selected archive, right?
[15:20] <cjwatson> err
[15:20] <cjwatson> that question doesn't make sense :)
[15:20] <sil2100> Like, if the user is part of the owning team etc.?
[15:21] <cjwatson> it does the same permission check that would be performed if you uploaded that package directly
[15:21] <cjwatson> that does not necessarily imply that the user is part of the owning team - archive upload permissions can be wider than the team that owns the archive
[15:22] <sil2100> Right, but still, it checks everything
[15:22] <sil2100> So I would like it to be called on the archive where the package is to be pushed to
[15:22] <fginther> Saviq, just to clarify, the unity-phablet-qmluitests-wily job can be dropped?
[15:22] <cjwatson> but most people don't have the ability to upload directly to the ci-train-ppa-service PPAs
[15:22] <cjwatson> it's basically core devs plus trainguards
[15:23] <cjwatson> sil2100: the reason I can think of why main_archive makes more sense is that the point of all of this is to enforce community standards for upload permissions
[15:23] <cjwatson> ci-train-ppa-service's upload permissions are an implementation detail
[15:23] <Saviq> fginther, everything -wily can go
[15:23] <cjwatson> the primary archive's permissions are not
[15:23] <Saviq> fginther, hmm or wait, that's our custom job
[15:24] <sil2100> cjwatson: the train is not only used to publish packages to the archives, it can also be used to publish to any PPA or any target - and the end goal is that this becomes self-service for anyone with the right permissions
[15:24] <Saviq> fginther, don't think the other one can do both vivid+o and wily at the same time?
[15:24] <sil2100> cjwatson: this is why I would really prefer if with each upload we check if we can upload to where we have the powers to
[15:24] <cjwatson> sil2100: sure, but the overlay PPA is a special case - it's meant to be broadly like the main archive, except that that's too annoying to arrange exactly
[15:25] <Saviq> fginther, basically, what we need is that the same set of jobs (build, qmluitests, autopilot) are run for both vivid+o and wily triggered from MPs into trunks
[15:25] <cjwatson> I don't think checking permissions on specifically the overlay PPA makes sense
[15:25] <fginther> Saviq, ok, I think that makes sense, The qmluitests would be executed by two different jobs, one for wily and one for vivid+overlay
[15:26] <fginther> for example
[15:26] <cjwatson> so perhaps that's rather that you should check the "permission-check archive", where that's self.dest except that the overlay PPA is overridden to main_archive
[15:26] <robru> sil2100: technically the train can publish "anywhere" but in practice nobody uses it for anything but overlay and Ubuntu archive
[15:26] <fginther> Saviq, it may take a little bit of time to implement and test all this, any suggested priorities for which project to do first?
[15:27] <sil2100> cjwatson: that makes sense
[15:27] <robru> cjwatson: your right, it should be main_archive.getPublishedSources
[15:27] <fginther> Saviq, also, if enabling the new builds outright fails, we'll let you know before turning it on for all MPs
[15:28] <Saviq> fginther, unity8 would be a prio (and most complex, too, because of the -qmluitests bit)
[15:28] <fginther> Saviq, got it, thanks
[15:28] <Saviq> fginther, that shouldn't happen, in theory, as we have both running now
[15:29] <fginther> Saviq, ok, we'll proceed with it just working then
[15:29] <sil2100> robru, cjwatson: modifying the branch then
[15:30] <sil2100> But I must say that I'm not super happy with that
[15:31] <Saviq> fginther, we have https://jenkins.qa.ubuntu.com/job/unity8-overlay-ci/ and https://jenkins.qa.ubuntu.com/job/unity8-ci/ today
[15:31] <fginther> Saviq, would we end up dropping unity8-overlay-ci ?
[15:31] <Saviq> fginther, yes, ideally
[15:34] <robru> sil2100: what's the problem? It'll fix your universe uploads right?
[15:35] <robru> I gotta run
[15:36] <sil2100> robru: yes, that's fine, but I prefer checking permissions of the selected archive where we want to upload
[15:41] <Saviq> fginther, as a stop-gap, could we move the -overlay job over to build lp:unity8 for now (along with unity8-ci itself)?
[15:43] <sil2100> Mirv: I'm testing the fix for the b0rken shortcuts on my desktop now
[15:44] <fginther> Saviq, I don't don't quite understand, you want unity8-overlay-ci to basically build against lp:unity8 instead?
[15:44] <Saviq> fginther, as a first step, yes
[15:44] <Saviq> fginther, unity8-ci already does, but for wily, unity8-overlay-ci would do for vivid+o, they'd fight on the MP vote, but we can deal with that for not
[15:44] <Saviq> now
[15:45] <fginther> Saviq, what target branch would it use, that's how jenkins finds MPs.
[15:45] <Saviq> fginther, lp:unity8
[15:47] <Saviq> fginther, we only want to use a single branch for both wily and vivid+o, and run testing for both releases
[15:47] <Saviq> so we either need two jobs triggered on every MP (stop-gap, if possible), or ideally a single job to run testing for both releases
[15:47] <Saviq> sorry if I'm not explaining myself clearly
[15:49] <fginther> Saviq, it's easier to to just update the single job config to run both, I can get started on it now if it's that much of a blocker
[15:50] <Saviq> fginther, that's fine then, I'd say high priority, not critical
[15:51] <Saviq> fginther, just thought it'd be easy to just flip the target branch for now and do The Right Thing™ later
[15:51] <fginther> Saviq, I thought that might work at first too, but the system is setup to prevent using the exact same branch in multiple locations
[15:53] <Saviq> fginther, yup, understand
[16:19] <slangasek> sil2100: the argument for checking the main archive perms instead of the overlay ppa perms was that the overlay ppa is an implementation detail of how we're doing the lightweight branching on vivid; and everything that's being landed in the overlay ppa also has to land in wily, so this should introduce minimal overhead
[16:21] <sil2100> slangasek: well, for the overlay case that holds true, I just really like things to stay universal and do the right thing, but anyway
[16:22] <sil2100> I proposed the change to fix looking at the main_archive permissions completely
[16:22] <slangasek> sil2100: right, and I argue that honoring the permissions for the main archive is universal, that we don't actually want multiple permission maps
[16:22] <fginther> Saviq, can you give this a quick review and confirm that removing support for lp:unity8/overlay and adding the vivid builds to lp:unity8 is what you had intended? https://code.launchpad.net/~fginther/cupstream2distro-config/unity8-wily-vivid-overlay/+merge/271341
[16:23] <fginther> Saviq, not asking for a detailed review, just that those two major changes are what you had in mind
[16:24] <Saviq> fginther, looks good, will the overlay hook play nice on the wily build?
[16:24] <fginther> Saviq, yes, I tested that with mir and it's a no-op on wily
[16:24] <Saviq> fginther, +1 from me then
[16:25] <fginther> Saviq, thx
[16:32] <sil2100> bzoltan: could be, I'm trying to find out something about that one
[16:40] <sil2100> pete-woods: ping! I'm building a no-change rebuild of the drivers in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-035
[16:40] <sil2100> Once those build could you check if that helps?
[16:40] <sil2100> pete-woods: if it doesn't, I'll fetch the latest version
[17:06] <sil2100> seb128: hey, how's the libusermetrics situation looking? ;)
=== alan_g is now known as alan_g|EOD
[17:26] <robru> slangasek: sil2100 is arguing for a general purpose use case that in practice nobody is using. Like if you wanted to publish packages to your personal ppa, you should be able to do that without being caught up on archive permissions.
[17:27] <robru> I'm not sure if i agree that that's a desirable thing to have...
[17:27] <robru> Need to think about it more
[17:31] <slangasek> robru: IMHO not something that should complicate the code before someone has actually asked for this functionality :)
[17:31] <sil2100> It wouldn't really complicate the code that much
[17:31] <sil2100> But I won't argue, I don't care enough
[17:34] <robru> slangasek: well the thing is that this feature was technically supported before, so my checkUpload implementation is technically a feature regression ;-)
[17:34] <slangasek> doesn't bileto implement a fixed list of supported publication targets?
[17:34] <robru> slangasek: it has a fixed list of suggestions. You can type any ppa n there
[17:36] <sil2100> We used that quite frequently in the past, now it's not used almost at all - since people were landing things through the CI Train to some tool PPAs, or even landing to some 'feature demo' PPAs
[17:37] <slangasek> ah, I see
[18:01] <fginther> Saviq, the requested lp:unity8 changes are live now
[18:47] <kenvandine> jgdx, dpkg-genchanges: warning: the current version (0.3+15.04.20150916.3-0ubuntu1) is earlier than the previous one (0.3+15.10.20150910.1-0ubuntu1)
[18:47] <kenvandine> nm, that's not really an error
[18:48] <kenvandine> looks like held packages in wily maybe
[19:32] <Saviq> fginther, great, thanks
[19:48] <jgdx> kenvandine, you know why the build keeps on failing on 64-bit? There's a libtimezonemap dep not satisfied
[19:49] <kenvandine> i did't look into it
[19:49] <kenvandine> but it's just wily
[19:49] <kenvandine> i'm thinking something might be held back in wily-proposed right now
[19:52] <jgdx> okay, thanks
[19:52] <kenvandine> oh... arm64
[19:54] <kenvandine> but it's there...
[19:56] <kenvandine> jgdx, ppc64el had failed too
[20:01] <kenvandine> jgdx, i kicked rebuilds for just ppc64el and arm64 in the PPA and they seem to have gotten farther
[20:01] <kenvandine> jgdx, so i did a watch only build to get the status in sync
[20:02] <kenvandine> hopefully all goes well
[20:02] <kenvandine> maybe the moon wasn't in alignment with the builders at the time :)
[20:08] <kenvandine> Preparing to unpack .../libtimezonemap1-dev_0.4.4_arm64.deb ...
[20:08] <kenvandine> Unpacking libtimezonemap1-dev (0.4.4) ...
[20:08] <kenvandine> jgdx, definately gotten further this time
[20:08] <kenvandine> jgdx, and ppc64el built this time
[20:16] <jgdx> kenvandine, aah thanks
[20:17] <jgdx> kenvandine, sorry, was filing a report :P
[20:21] <kenvandine> jgdx, no worries, i think it'll build this time
[20:21] <jgdx> kenvandine, wonderful. Have a good night!
[20:21] <kenvandine> you too