[00:00] <cjwatson> robru: OK, we've thought of one detail that needs to be put in place to make sure that translation message sharing works properly before starting imports, but I know what to do now and the translations can sit in the import queue until I've done it.
[00:01] <robru> cjwatson: OK, need anything from the train side?
[00:04] <cjwatson> robru: Nope, thanks
[00:05] <cjwatson> Best collect the hacks for this in one place
[00:05] <robru> cjwatson: great, thanks for taking care of that.
[00:05] <cjwatson> I feel kind of dirty but at least it wasn't too hard :-)
[00:07] <cjwatson> There's also a hidden dependency here on the fact that the silos are devirtualised, which is the only reason that translations are getting stripped
[00:07] <cjwatson> But we can just keep that flag even after devirtualisation otherwise no longer matters
[00:08] <cjwatson> Well, except ephemeral PPAs, hmm, will have to think about that
[00:11] <robru> cjwatson: ephemeral train silos are a long way off, no hurry
[00:13] <cjwatson> robru: Indeed, but in part because LP won't let you create them.
[00:13] <cjwatson> We like to not be in people's way for important projects.
[00:13] <robru> cjwatson: haha, indeed
[00:13] <robru> cjwatson: is it just that we can't create devirt ppas, or does lp api actually not allow ppa creation at all?
[00:16] <cjwatson> robru: Oh, you can create them, but you can't configure them the way silos should be configured (especially but not limited to devirt) without giving ci-train-bot a scary amount of privilege.  And anyway other bits of the workflows for PPAs we expect to be deleted and forgotten about at the end probably aren't quite right.
[00:16] <robru> cjwatson: I see.
[00:17] <cjwatson> It's moot until we get scalingstack for all arches, anyway, but shouldn't be too hard at that point.
[00:18] <cjwatson> A thing that lets you configure relatively unprivileged aspects of PPAs would be not that scary, it's just devirt that's kind of verging on admin privileges.
[00:18] <robru> cjwatson: yeah definitely don't want bots with admin.
[00:18] <cjwatson> What's the work on your end?
[00:18] <cjwatson> Just the logic to create and clean up?
[00:18] <robru> cjwatson: yeah basically
[00:18] <cjwatson> Or is there non-trivial assignment logic as well?
[00:19] <robru> cjwatson: currently it determines what silos exist by querying lp api, would need to change some of that logic to care less about what PPAs exist and just create them as necessary.
[00:19] <cjwatson> I guess it would mostly be deleting code.
[00:19] <robru> cjwatson: depends how many lp api calls it would take to create the PPA with the right settings.
[00:20] <robru> cjwatson: lots of ppa-discovery code would go away, but then lots of ppa-creation and deletion code would take it's place
[00:21] <cjwatson> We could probably just give person.createPPA more arguments.
[00:21] <cjwatson> No point in making you create and configure it separately just because we hate you and want you to write more code or something.
[00:21] <robru> hehe
[00:22] <robru> cjwatson: it's probably not a huge change measuring by lines of code, but there's certain architectural assumptions that would have to change and that could have some growing pains.
[00:23] <cjwatson> k
[00:23] <cjwatson> Well, scalingstack for everything is still probably months away not weeks, so no rush
[00:23] <robru> cjwatson: anyway, we're focused on the spreadsheet replacement for now so the ephemeral PPAs thing isn't blocking us badly.
[00:23] <cjwatson> OK
[01:23] <veebers> robru: still around perchance? :-)
[01:24] <robru> veebers: yeah what's up
[01:25] <veebers> robru: hey :-) First, is it possible to make the new citrain site https only? (I get a warning dialog when using it)
[01:26] <robru> veebers: production will be https. I didn't bother to make a cert for the staging area.
[01:27] <veebers> robru: ah, ack :-) Second, prob dumb Q, landing for the devices (i.e. overlay ppa) which distro is that? ubuntu or ubuntu-rtm?
[01:27] <robru> veebers: it's all ubuntu for now
[01:27] <veebers> robru: ah ack, thanks for the clarification :-)
[01:27] <robru> veebers: you're welcome
[01:56] <veebers> robru: if you're still around :-) seems packages failed to build due to signing. http://ci-train.staging.ubuntu.com/job/ubuntu-landing-001-1-build/1/console
[01:59] <robru> veebers: just eating, will look later, thanks for trying.
[02:00] <veebers> robru: nw. Should I be using the old spreadsheet if I need this landed or will this do the jobfor me?
[02:11] <robru> veebers: you need the spreadsheet for a real landing. The staging area is not eligible for real publishing to distro
[02:12] <veebers> robru: oh, hah, sorry I had the wrong end of that :-) I'll fire up a spreadsheet landing now
[02:12] <robru> I'm hoping this'll go live in a week or two
[02:15] <robru> veebers: i think you looked at the wrong part of that log. Build failed in ppa: https://launchpadlibrarian.net/211049255/buildlog_ubuntu-wily-amd64.autopilot_1.5.1%2B15.10.20150708-0ubuntu1_BUILDING.txt.gz
[02:16] <robru> veebers: you can now assign your own from the spreadsheet, enjoy ;-)
[02:16] <veebers> robru: I hope it goes live too, its a much nicer interface
[02:18] <robru> veebers: thanks
[03:31] <veebers> trainguards, I've been told I can assign a silo from the spreadsheet, unsure how though
[03:37] <robru> veebers: "landing tools > assign/reconfigure" menu
[03:37] <jdstrand> fyi, pmcgowan said this (line 82) needs to land tomorrow (part of fix for bug #1462489)
[03:38] <robru> jdstrand: you can now assign your own silos. Go crazy
[03:38] <jdstrand> oh, I missed that
[03:38] <robru> jdstrand: let me know if you need any help
[03:39] <jdstrand> robru: where are the instructions? on ubuntu-phone?
[03:39] <robru> jdstrand: no instructions really, this is a small change phased in ahead of the larger spreadsheet replacement change coming soon
[03:40] <robru> jdstrand: just go to the landing tools menu and follow the prompt to assign
[03:40] <robru> jdstrand: veebers make sure the right row is highlighted first
[03:40] <veebers> robru: ah coolio, thanks
[03:40] <veebers> ack
[03:40] <jdstrand> robru: oh, cool :)
[03:40] <robru> veebers: you're welcome
[03:41] <robru> I'm eod 3 hours ago but happy to help if anything goes wrong
[03:44] <veebers> robru: nice, thanks :-)
[03:45] <jdstrand> robru: worked well, thanks :)
[03:45] <robru> veebers: jdstrand you're welcome!
[04:56] <Mirv> and I'm awake now
[06:33] <oSoMoN> Good morning trainguards! Can I have a silo for line 83, please?
[06:33] <Mirv> oSoMoN: done, silo 035
[06:33] <oSoMoN> Mirv, thanks!
[07:25] <jamesh> jibel: hi.  With the problems you highlighted in the thumbnailer (silo 10), what exactly did you see on arale? Black thumbnails, a placeholder image, or something else?
[07:40] <ogra_> woah
[07:41] <ogra_> what made the session startup so slow ?
[07:41] <ogra_> it takes a felt 20sec more with todays image
[07:45] <ogra_> woah ... over 80seconds ...
[07:45] <ogra_> that used to be way below 1min ... (krillin)
[07:46] <ogra_> jibel, davmor2 ^^^ did that not happen during QA testing ?
[07:53]  * ogra_ files bug 1472507
[07:55] <jibel> ogra_, I didn't see that but victorp mentioned it yesterday too. I'll have a look.
[07:56] <ogra_> victorp, ^^^ you might want to "ne too" that (or duplicate it against your bug if you opened one)
[07:56] <ogra_> *me too
[07:57] <ogra_> (so it gets confirmed status)
[07:57] <popey> ogra_: how long does arale take to boot for you on 51? from vibrate to lock screen?
[07:58] <ogra_> right now, yeah, it was way less before
[07:58] <ogra_> between 30 and 40
[07:58] <ogra_> i think sturmflut said hiw boots in 22sec :) not sure how he measured that :)
[07:59] <popey> i have 50 on my arale and it takes 50 s
[07:59] <popey> so not sure it's image 51
[08:05] <ogra_> i didnt notice it yesterday morning ... could indeed also have been 49 to 50 where it broke ...
[08:05] <ogra_> i definitely know it wasnt that slow on monday
[08:09] <popey> new unity8 on monday :)
[08:10] <victorp> ogra_, ack
[08:13] <jibel> ogra_, it is slow right after the upgrade or on every boot?
[08:16] <seb128> could somebody get https://bugs.launchpad.net/canonical-devices-system-image/+bug/1472161 on the milestone list?
[08:16] <jibel> ogra_, ok, 1:40 from the moment the screen turns on with the bq logo to the first sim prompt on krillin.
[08:16] <seb128> that's sile 35 and a regression in ota5
[08:18] <jibel> ogra_, and 18s on arale
[08:19] <jibel> same image
[08:23] <jamesh> jibel: hi.  Could you provide a bit more detail about the problems on arale that you encountered testing the thumbnailer in silo-010?  What did the missing thumbnails look like?
[08:35] <jibel> jamesh, Hey, missing thumbnails look like a placeholder image
[08:35] <ogra_> jibel, yeah, 1:40 isnt good, we were below a minute ... and yes, i can reproduce it every boot
[08:35] <popey> odd, fine here.
[08:36] <jibel> ogra_, I know it isn't good, especially compared to arale
[08:36] <jamesh> jibel: but all other thumbnails showed up correctly? (just want to make sure the thumbnailer-service package got installed correctly: it gets skipped by "citrain device-upgrade" if you don't have libleveldb1 installed)
[08:37] <jibel> jamesh, the package was installed, I don't use citrain device-upgrade and do it manually
[08:37] <ogra_> jamesh, the solution to that is to copy libleveldb1 into your silo (citrain install disables the main archive to not taint the testing)
[08:38] <jamesh> jibel: okay.  I wouldn't mind seeing an excerpt from ~/.cache/upstart/dbus.log when this occurs.
[08:38] <sil2100> jibel, ogra_: can we somehow identify when this regressed?
[08:38] <ogra_> sil2100, well, i can only say it regressed today for me
[08:38] <jibel> jamesh, okay, I'm looking into this long boot issue which is more pressing and will reinstall the silo afterward
[08:38] <ogra_> and it doesnt seem to be consistent ... some people do not see it it seems
[08:38] <sil2100> Then somewhere here http://people.canonical.com/~lzemczak/landing-team/ubuntu-touch/rc-proposed/60.commitlog
[08:39] <ogra_> while jibel victorp and i can repro it, popey and sturmflut can not
[08:39] <ogra_> sil2100, i linked to my changelo in the bug ...
[08:39] <jibel> ogra_, when you test your device is plugged or unplugged to usb?
[08:39]  * ogra_ checks your link
[08:39] <victorp> ogra_, mind you , I only managed to repo on arale, krillin updated fine
[08:40] <ogra_> sil2100, yeah, looks similar
[08:40] <jibel> for me it's the other way arale is fine but not krillin
[08:40] <ogra_> jibel, unplugged
[08:40] <sturmflut2> Good morning!
[08:41] <ogra_> i wouldnt call it critical, everything seems to work fine beyond that
[08:41] <ogra_> (not a OTA blocker)
[08:41] <ogra_> but it is definitely noticeable and annoying
[08:41] <ogra_> hey sturmflut2
[08:42] <jibel> ogra_, it is not consistent, this time the device booted in 55s
[08:42] <ogra_> funny
[08:42]  * ogra_ reboots his krillin again
[08:43] <sil2100> I'll upgrade my krillin and see if I see the same  thing
[08:43] <popey> sil2100: want these new clicks uploaded to the store?
[08:43] <ogra_> while i like most of the new icons, the cellular one is really awful in its steepness
[08:43] <sil2100> popey: yes please :)
[08:43] <popey> ok
[08:46] <sil2100> Ok, anyway, let's close the landing gates - I see we might have some blocker fixes approved to land anyway, but for now we lock down
[08:46] <ogra_> jibel, exactly 100sec this time ... 20sec for the bootsplash ... which is usual and 80 with the usc spinner
[08:46] <jibel> sil2100, there is a request for a device tarball for arale on the spreadsheet, do you know if it landed already?
[08:47] <jibel> ogra_, that's what I saw during previous boot
[08:48] <sil2100> jibel: ah, the second one? Not sure, I hope alextu checks the spreadsheet... let me ask
[08:48] <ogra_> hmm
[08:48] <ogra_> and my arale just did it in around 20sec
[08:48] <ogra_> (the full boot)
[08:48] <sil2100> jibel: I see there's yet another device tarball that was ready
[08:49] <ogra_> yeah, and again ... seems my arale only was slow for the first few boots, now it seems fast
[08:50] <sil2100> My arale is fast as lightning
[08:51] <sil2100> ogra_: hm, my krillin rebooted pretty fast
[08:52] <ogra_> 95sec here again
[08:53] <ogra_> well, someone should bootchart that ... sadly i'm busy with preparing a snappy release today :/
[08:57] <jibel> 33s on krillin, the more I reboot, the faster is goes :)
[08:58] <sil2100> jibel: we have the last device tarball, we'll need now someone to sign off the new one - it has the notification led fix in it
[08:58] <jibel> s/is/it
[08:58] <jibel> sil2100, ok
[08:58] <sil2100> Still writing the announcement e-mail, too much distractions
[09:06] <jibel> ogra_, could the device try to suspend during boot like it did during shutdown?
[09:06] <ogra_> it did  ?
[09:06]  * ogra_ never heard of that
[09:06] <jibel> ogra_, maybe I misremember the exact cause but there was a long shutdown issue
[09:07] <jibel> ogra_, anyway, when the devices is plugged boot time is always between 30 to 35s
[09:07] <ogra_> well, thats usually due to wrong stop on lines in upstart jobs
[09:07] <ogra_> let me plug in mine
[09:08] <ogra_> 16sec bootsplash
[09:09] <ogra_> 20sec session
[09:09] <ogra_> wow !
[09:10] <popey> sil2100: calculator, calendar, clock, music, notes (reminders), shorts and weather all updated with new icons in the store.
[09:10] <sil2100> popey: thank you!
[09:10] <sil2100> Excellent
[09:11] <ogra_> unplugged: 20sec bootsplash, 80sec session again
[09:19] <seb128> jibel, do you think bug #1472161/silo 35 can/should be included in the ota5 landings? (it's to fix a regression in the current candidate)
[09:20] <sil2100> seb128: we'll have to wait for Pat to pop-up for a final decision anyway... but in overall we don't like regressions
[09:21] <jibel> seb128, yeah, set it to ready for QA and we'll try to land it
[09:21] <seb128> jibel, thanks
[09:39] <Laney> AlbertA: how did qtubuntu-* end up getting in?
[09:43] <jibel> sil2100, so the plan is to try to land what is currently in the ready for testing queue + silo 35 seb128 mentioned earlier if it is ready on time. Then you can build a first candidate.
[09:43] <jibel> sil2100, Is there anything else to land?
[09:44] <jibel> sil2100, I think we needed a policy group fix for qtsystem that landed yesterday
[09:45] <seb128> jibel, oSoMoN: I just tested silo 35 and marked it as testing pass on the ci table
[09:48] <oSoMoN> seb128, thanks, I also validated it on my side, I was waiting for someone on my team to review it, but if we’re in a hurry I think it’s perfectly safe to land now
[09:56] <seb128> oSoMoN, no idea when it needs to land, but today I guess
[09:56] <seb128> qa can verify it meanwhile
[09:57] <oSoMoN> seb128, yeah, landing today would be good
[10:02] <pstolowski> trainguards, hello, silo 42 has been in proposed pocket for quite a while (for around 20hrs i think), any idea why is that?
[10:04] <seb128> pstolowski, https://launchpad.net/ubuntu/+source/unity-scopes-api/0.6.19+15.10.20150706.1-0ubuntu1
[10:05] <seb128> pstolowski, it failed to build on arm64 it seems
[10:07] <pstolowski> seb128, ah
[10:08] <seb128> pstolowski, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html is the url to check for proposed migrations
[10:08] <Mirv> pstolowski: https://launchpadlibrarian.net/210999339/buildlog_ubuntu-wily-arm64.unity-scopes-api_0.6.19%2B15.10.20150706.1-0ubuntu1_BUILDING.txt.gz - does that look something that might fail occasionally? it can be rerun.
[10:08] <Mirv> pstolowski: I just wonder how it was possible to publish that since it should have warned in CI Train if it failed to build in a silo for one arch
[10:09] <pstolowski> Mirv, exactly... shall I then just kick the build of unity-scopes-api?
[10:10] <Mirv> pstolowski: why all train users are so trigger happy with new builds to fix one arch! it should be made more painful :D so no, it's already published, and single archs need to be restarted by trainguards manually (either in silo or in archives)
[10:11] <jibel> ogra_, ah I got a slow boot. I adbshelled to the device and apport was running. unity8 crashed
[10:11] <ogra_> jibel, hah !
[10:11] <Mirv> pstolowski: rerunning now at https://launchpad.net/ubuntu/+source/unity-scopes-api/0.6.19+15.10.20150706.1-0ubuntu1/+build/7628619 - but if it fails, it might be something needs to be changed, rebuilt, and republished
[10:11] <jibel> ogra_, can you check if you have any crash file corresponding to a slow boot
[10:11] <jibel> in a previous boot it was maliit-server
[10:12] <seb128> pstolowski,
[10:12] <seb128> 18: Value of: (db->settings()["locationSetting"].get_string())
[10:12] <seb128> 18:   Actual: "London"
[10:12] <seb128> 18: Expected: ("New York")
[10:12] <pstolowski> seb128, yeah, i know, this test is a bit racy
[10:12] <seb128> pstolowski, k, so should the build be retried?
[10:12] <seb128> pstolowski, do you have a bug about the test not being stable?
[10:16] <pstolowski> seb128, yes, should be retried; no bug yet
[10:18] <seb128> pstolowski|lunch, can you open one?
[10:19] <pstolowski|lunch> seb128, willd do
[10:20] <seb128> thanks
[10:22] <popey> sil2100: today scope still has old calendar icon, do you know if that's being updated?
[10:31] <sil2100> popey: hm, not sure
[10:31] <jibel> rvr, I take silo 21 can you do 35 after 26?
[10:31] <rvr> jibel: Yes
[10:31] <sil2100> jibel: just so you know... silo 36 might need to be landed as an exception as well
[10:31] <popey> sil2100: I'll ask the icon designer
[10:31] <sil2100> jibel: it seems management wanted that
[10:33] <jibel> sil2100, well if we want to release something it has to stop at some point. The silo is not even built
[10:33] <sil2100> jibel: yeah... mzanetti is rebuilding it since some other silo landed in the meantime
[10:33] <mzanetti> sil2100, jibel: nope. silo7 hasn't landed yet
[10:33] <mzanetti> will have to rebuild after that
[10:33] <sil2100> It's for the arale look and feel
[10:34] <sil2100> mzanetti: is 007 more important?
[10:34] <mzanetti> currently just building/testing to be prepared for when the other is out of the way
[10:34] <mzanetti> sil2100, it's not... but it's approved and tested by gerry already
[10:34] <sil2100> Yeah, but QA is not testing it yet, so I would say we should prioritize
[10:35] <ogra_> jibel, yes, lots .. unity8, -dash, maliit and whoopsie-upload-all
[10:38] <jibel> ogra_, that would explain why it is inconsistent, if the same process crash again it won't be reported
[10:42] <seb128> pstolowski|lunch, retry failed on the same test, I do another retry
[10:48] <ogra_> jibel, yeah
[11:15] <jibel> ogra_, and again, unity8 unity8-dash and maliit crashes, it took nearly 2 minutes to boot
[11:15] <ogra_> wow, that starts to sound more critical
[11:40] <ogra_> jibel, hmm, my arale just locked up hard ... doesnt take inout
[11:40] <ogra_> *input
[11:44] <cwayne> can the ci train spreadsheet replacement work for click packages/tarballs?
[11:44] <cwayne> sil2100: ^
[12:01] <pstolowski> seb128, hmm if this keeps failing I may need to rollback on of the changes from that silo which perhaps made things worse than before
[12:10] <Mirv> ogra_: around? https://ci-train.ubuntu.com/job/ubuntu-landing-003-2-publish/lastSuccessfulBuild/artifact/ubuntu-ui-toolkit_packaging_changes.diff - one universe binary package (ubuntu-ui-toolkit-autopilot) new dependency on an universe package, is that ok?
[12:10] <Mirv> even though src plus some of the other binary packages are in main
[12:10] <ogra_> Mirv, as long as it is properly mentioned in the changelog :)
[12:11]  * ogra_ will take a look soon (sorry, busy atm)
[12:11] <Mirv> ok
[12:12] <sil2100> cwayne: yes :)
[12:12] <sil2100> cwayne: it doesn't build them, but it can be used to track non-train landings
[12:13] <Mirv> rhuddie: hey! your UITK commit message does not include the information about addind a new dependency in debian/control, which is a requirement for any debian/ changes
[12:13] <cwayne> sil2100: neat!
[12:15] <ogra_> rhuddie, i usually dont sign off packages that dont explicitly mention the dependency change ... please make sure to do this properly next time ... (for now i'll approve it)
[12:15] <ogra_> Mirv, with the above .... ACK
[12:17] <sil2100> My arale battery is really good since the few last updates
[12:18] <rhuddie> Mirv, ogra_, ack. I'll remember for future so its not missed
[12:18] <Mirv> ogra_: :( I mean, nice for ack, not nice for your quest for educating people being hard. FYI the bug of autochecking that by CI Train was deemed a bit hard to implement.
[12:18] <Mirv> I still think that's the only right way, CI check for it.
[12:18] <ogra_> yeah, i can imagine that the logic for that is hard
[12:27] <jibel> ogra_, the dash crash I get on boot is bug 1363946
[12:27] <jibel> mzanetti, ^
[12:28] <seb128> pstolowski, yeah, 3rd retry failed as well, doing another one but you might consider looking at fixing the issue or disabling the test if it's a buggy one
[12:28] <seb128> or better fixing it ;-)
[12:28] <jibel> ogra_, maliit-server is https://errors.ubuntu.com/oops/6874ad2a-2562-11e5-8f47-fa163e525ba7 but not fully retraced and quite popular on 15.04
[12:28] <pstolowski> seb128, is there an arm64 machine i could access and debug this test?
[12:29] <jibel> and unity8 failed to retrace completely
[12:29] <pstolowski> seb128, i'm just running this test in a loop on the desktop and it passess...
[12:29] <seb128> pstolowski, try asking on #ubuntu-devel about porting boxes, or try arm64-porter.canonical.com
[12:30] <ogra_> jibel, well, i'm not as concerned about it crashing on every boot as i am about the hard lock
[12:32] <pstolowski> seb128, ok, thanks
[13:22] <jdstrand> pmcgowan: hey, apparmor-easyprof-ubuntu is in silo 17 for stable-phone-overlay and I'm finishing up testing now
[13:22] <jdstrand> pmcgowan: I wasn't sure what to put in 'QA signoff needed' though
[13:22] <pmcgowan> jdstrand, awesome, jibel ^^
[13:24] <jdstrand> pmcgowan: /win 29
[13:24] <jdstrand> meh
[13:28] <rvr> boiko: Silo 26 approved
[13:28] <boiko> rvr: great! thanks a lot!
[13:28] <boiko> salem_: ^
[13:29] <salem_> boiko, rvr awesome, thanks.
[13:31] <jibel> rvr, can you pick silo 17 when it's ready?
[13:31] <rvr> jibel: Ack
[13:32] <jibel> jdstrand, can we start the verification of silo 17 or you think it's better to wait until you finished testing?
[13:32] <rvr> Packages built
[13:52] <bfiller> sil2100. popey: has anyone uploaded the new camera app to the store yet?
[13:53] <sil2100> bfiller: I don't think so...
[13:53] <sil2100> bfiller: we only landed it to the archive
[13:53] <sil2100> popey: ?
[13:53] <bfiller> sil2100: I was out last two days, needs to happen. I can do it now, hopefully the final image hasn't been spun yet
[13:53] <popey> Nope
[13:53] <popey> I only did gallery
[13:54] <sil2100> bfiller: no worries, silos still being signed off and translations in progress of being exported
[13:54] <bfiller> sil2100: cool, will do now
[13:54] <sil2100> bfiller: so please release :)
[13:54] <sil2100> Thanks
[13:57] <jdstrand> jibel: go ahead
[13:58] <mzanetti> sil2100, pmcgowan: ok. 36 good to go
[13:58] <sil2100> o/
[13:58] <sil2100> My target date to kick the new image is around 19 of my time, so in ~3 hours
[13:59] <pstolowski> Mirv, seb128 about that test failure on arm64 and silo 42: it's not clear why it fails only on this arch, i've requested access to arm64 box to debug this, but it may take time. does this block entire landing? if so, then I'll prepare MP that disabled that test for this landing
[14:00] <pstolowski> and will continue debugging
[14:03] <jdstrand> jibel: note, you can skip the autopkgtest-- I forgot to update it for the new policygroup so there is a failure on the unexpected 'keep-display-on' policy group. that doesn't affect the functionality in the package in any way (and I am staging the fix for that now for next time)
[14:11] <pstolowski> sil2100, hey, I think I need to sort out the issue with silo 42 mentioned above, it has critical fix affecting battery ^
[14:18] <AlbertA> Laney: qtubuntu-android qtubuntu-desktop depends on qtubuntu-sensors and they have the ubuntu-application-api3-touch(desktop) dependency
[14:27] <jibel> pmcgowan, is there anything else on the "need sign-off" queue that must land this week? It's a bit late to land 36
[14:28] <pmcgowan> jibel, 36 and the device tarball that goes with it, sorry for the last min as usual
[14:28] <jibel> davmor2, ^ can you do it?
[14:28] <pmcgowan> jibel, the apparmor change
[14:28] <pmcgowan> you know about
[14:29] <jibel> pmcgowan, rvr is on the apparmor change
[14:29] <pmcgowan> device tarball won't arrive till first thign tomorrow from asia
[14:29] <seb128> pstolowski, yeah, that build issue is a migration blocker
[14:30] <pmcgowan> jibel, and silo 53 is that landing?
[14:30] <davmor2> pmcgowan: not another tarball I only signed one off this morning ;)
[14:30] <pmcgowan> job security
[14:30] <bfiller> popey: camera uploaed
[14:30] <bfiller> popey: mind approving it in store?
[14:30] <davmor2> jibel: I can do it once I finish this browser one maybe 30-60 minutes
[14:31] <pstolowski> seb128, in that case I'm disabling the test for now and will rebuild the silo. this will not require any re-testing from qa
[14:31] <pstolowski> jibel, ^
[14:31] <seb128> pstolowski, k
[14:31] <pmcgowan> jgdx, pete-woods how is silo 53?
[14:31] <cjwatson> sil2100: Oh, I told Robert about this last night, but you'd left by then.  Translations are being correctly uploaded to ubuntu-rtm/15.04 for copies to stable-phone-overlay now.  However, we thought of a detail we need to sort out (ensuring Packaging records so that message sharing works) before we can turn on import queue processing and permit translations.  I'm working on that.
[14:31] <cjwatson> pmcgowan: ^- FYI
[14:32] <jibel> pmcgowan, we cannot start regression tests tomorrow otherwise we won't make it on time. And silo 36 touches core components
[14:32] <pete-woods> pmcgowan: I've tested it, and it seems to work
[14:32] <pmcgowan> cjwatson, ack
[14:33] <pmcgowan> jibel, will we also wait for the crashes to be fixed? that ogra_ mentioned above
[14:33] <ogra_> pmcgowan, it is hard to tell what impact (beyond boot time) they have
[14:35] <jgdx> pmcgowan, davmor2 is currently the only one (the chosen one) able to test this properly AFAIK
[14:35] <jgdx> pmcgowan, re: silo 53
[14:35] <davmor2> jgdx: oh not more peap stuff
[14:35] <jgdx> oh yes indeed
[14:36] <pmcgowan> so 36 and 53 seem the last to land
[14:37] <davmor2> jibel: I can probably test both, but I assume the preference now will be 53 I assume right?
[14:37] <pmcgowan> and 35 fixes a regression I see
[14:38] <jibel> 35 will land soon
[14:38] <davmor2> pmcgowan: testing 35 now
[14:39] <pmcgowan> jibel, 39 is the only other one to consider
[14:41] <popey> sure bfiller
[14:43] <popey> bfiller: done
[14:43] <bfiller> popey: thanks
[14:44] <rvr> jdstrand: I need a test app for silo 17
[14:46] <pmcgowan> mzanetti, do you have an app for rvr?
[14:47] <mzanetti> pmcgowan, rvr, one sec. I'll update the one from yesterday to not be unconfined, but use the apparmor permission we need to test this
[14:47] <rvr> mzanetti: Thanks
[14:53] <mzanetti> rvr, http://notyetthere.org/data/untitled5.mzanetti_0.2_all.click
[14:53] <mzanetti> rvr, this uses the "keep-display-on" policy as said in the bug. I didn't test it on the silo to
[14:54] <jdstrand> rvr: I put one in the bug
[14:55] <jibel> mzanetti, could you split 36 and build a silo with only GU related changes?
[14:55] <jibel> pmcgowan, ^
[14:55] <jdstrand> I see mzanetti also has one
[14:55] <mzanetti> jibel, reason?
[14:55] <mzanetti> jibel, yes I can do.. but obviously requires a rebuild etc
[14:56] <rvr> jdstrand: Ahh... test-keep-display-on.jdstrand_0.1_all.click
[14:56] <pmcgowan> mzanetti, what else is in there
[14:56] <rvr> jdstrand: I'll check it too
[14:56] <mzanetti> pmcgowan, some test improvements that I had in there earlier already
[14:56] <mzanetti> but sure, I can drop them, no prob
[14:56] <jdstrand> rvr: ok-- but it is just mzaneeti's qml file :)
[14:56] <jdstrand> mzanetti's*
[14:57] <pmcgowan> mzanetti, jibel just trying to avoid risk
[14:57] <mzanetti> I understand. ok. rebuilding then, ok?
[14:57] <mzanetti> jibel, ^
[14:58] <jibel> mzanetti, yes
[14:59] <mzanetti> that line seems a bug btw ^ (I've set it from yes to no)
[15:20] <oSoMoN> trainguards: can silo 35 be published, please?
[15:29] <awe> pmcgowan, do we promote OTA candidate images to flash-able channel?
[15:30] <awe> if not, I guess rc-proposed would be sufficient...
[15:39] <pmcgowan> awe, not sure I follow, yes its rc-proposed
[15:39] <pmcgowan> awe, there is an rc channel actually but nt really used for that
[15:39] <awe> yea, after some thought, it was a dumb question
[15:39] <awe> ;)-
[15:42] <bfiller> pmcgowan: is there a known issue with installing apps from the store? seems to not be working for me on latest image
[15:43] <bfiller> get error "Download or install failed. Please try again."
[15:45] <pmcgowan> bfiller, not that I am aware of
[15:46] <pmcgowan> bfiller, oh my
[15:46] <pmcgowan> failed here as well
[15:46] <bfiller> busted
[15:46] <bfiller> maybe something with the 2-factor auth?
[15:46] <pmcgowan> store or image is the question
[15:46] <pmcgowan> jibel, ^^
[15:48] <pmcgowan> bfiller, checking with martin as I bet you are right
[15:49] <rvr> jdstrand: jibel: Silo 17 looks good
[15:50] <jibel> pmcgowan, bfiller fails here too
[15:51] <jibel> bfiller, I've this in the logs of scope-registry: Error received from UDM during startDownload: Network Error
[15:54] <pmcgowan> bfiller, jibel I am told prodstack went down so downloads busted
[15:55] <bfiller> pmcgowan: ok, thanks
[15:55] <jibel> pmcgowan, thanks
[15:59] <jdstrand> jibel: fyi, re silo 17, I haven't been able to complete the image/unprivileged/apparmor-easyprof-ubuntu because it is a long running test and something is stopping adb and killing the test. I'm bringing up an alternate device to test on. If rvr was able to complete the test run, I don't think you need to wait on me
[15:59] <jdstrand> jibel: let me rephrase, I am using 'adb shell ...' and something unrelated to the test is breaking the connection
[16:00] <jdstrand> which of course makes the test not complete. but, like I said, I am now trying on a different device
[16:01] <rvr> jdstrand: I was able to verify that the new feature works fine
[16:02] <jdstrand> yes, I was able to do that
[16:02] <jdstrand> I was referring to the test plan
[16:06] <rvr> jdstrand: The manual tests are ok.
[16:06] <jdstrand> cool
[16:07] <jdstrand> I'm highly confident in this upload between what you've done and the test plan I was able to complete (and like I said, trying to complete that test on a different device that doesn't break the adb connection)
[16:08] <cjwatson> prodstack> One PS4 compute node went down
[16:15] <jdstrand> meh, the adb connection keeps breaking
[16:15]  * jdstrand tries on emulator
[16:21] <pmcgowan> bfiller, jibel store is back up
[16:22] <sil2100> oSoMoN: was AFK, publishing now
[16:29] <dbarth__> hey trainguards o/ can i have a silo for line 86 ?
[16:30] <oSoMoN> sil2100, thanks!
[16:31] <sil2100> On it
[16:33] <oSoMoN> trainguards: is it possible to publish a dual silo to wily only?
[16:34] <robru> oSoMoN: it is, basically I just have to delete the vivid packages
[16:34] <oSoMoN> robru, ok, I’ll want to publish silo 8 to wily only tomorrow (still need to validate it a bit more)
[16:35] <popey> pmcgowan: store is broken here
[16:35] <robru> oSoMoN: ok no worries, I'll wait to delete the packages just in case you change your mind. just remind me when it's ready to publish.
[16:35] <popey> pmcgowan: nothing is downloading - all at 0% on multiple devices
[16:37] <oSoMoN> robru, will do, thanks
[16:38] <robru> oSoMoN: you're welcome
[16:43] <sil2100> pmcgowan, jibel: still some time needed until I can build the candidate image... exports are still ongoing
[16:47] <jibel> mzanetti, is 36 ready for QA?
[16:48] <mzanetti> jibel, ah, it has built. I would day yes, but just to make sure, I'll do a quick test before making you guys work
[16:52] <cjwatson> sil2100: Looks like it completed 13 minutes ago, in fact
[16:52] <cjwatson> Bit quicker than my linear guesstimate suggested
[16:54] <pstolowski> sil2100, i'm still waiting for silo 42 to finish... 2h 10 min already!
[16:55] <mzanetti> jibel, ready
[17:00] <jibel> mzanetti, thanks
[17:02] <jibel> rvr, alesage om26er : silo 36 is ready, anyone?
[17:02] <om26er> jibel, I'll
[17:05] <pstolowski> seb128, ping
[17:08] <jibel> om26er, thanks
[17:34] <jdstrand> jibel, rvr: silo 17 testing complete
[17:35] <jdstrand> jibel: "Testing pass. QA needs to signoff"
[18:09] <om26er> mzanetti, Hi!
[18:09] <om26er> mzanetti, re: silo36 what do I need to edit to be able to test the GU change ?
[18:10] <ogra_> hmpf ... so now i permanently have a "add your fitbit account" on my today screen ?
[18:10] <ogra_> wow
[18:10] <ogra_> seems it wiped all my settings ... thats evil
[18:19] <alecu> pmcgowan: hi! pstolowski tells me that this bug is "in progress", not "released": https://bugs.launchpad.net/canonical-devices-system-image/+bug/1470750
[18:19] <anpok_> ping trainguards
[18:19] <robru> anpok_: hi
[18:19] <anpok_> hi
[18:19] <anpok_> now I read the console output..
[18:19] <alecu> pmcgowan: it was not able to land because one test failed in arm64
[18:19] <anpok_> hmm of the ci silo reconfigure script
[18:19] <anpok_> it says sources and sync_requests not supported
[18:19] <anpok_> I thought they worked before?
[18:20] <pstolowski> pmcgowan, yes, it was only merged into devel, maybe that was confusing. i've been fighting with the silo to get it landed, but the build is still in progress
[18:20] <alecu> pmcgowan: we are not able to change the status for that bug in Canonical System Image
[18:21] <anpok_> robru: ubuntu/landiing-004 - dual landing silo I just had to replace qtubuntu-gles MP
[18:25] <mzanetti> om26er, re
[18:25] <mzanetti> om26er, check out the description here: https://code.launchpad.net/~mzanetti/unity8/40-50-90/+merge/263488
[18:25] <robru> anpok_: no SOURCES and SYNC_REQUEST never really "worked" with dual landings, the behavior was undefined.
[18:26] <robru> anpok_: the check to prevent that situation from happening is new though. what are you trying to do?
[18:27] <robru> anpok_: if you are able, the best thing to do is use MPs for everything. If you have packages you can't use MPs for, you need to release to wily first then sync back to vivid.
[18:27] <om26er> mzanetti, thanks, did the changes and rebooted, lets see
[18:29] <sil2100> rvr: ping
[18:29] <robru> anpok_: You have sources marked as "glmark2 xorg-server gtk+3.0". is your intention really to build wily+vivid copies of both of those manually? much easier to just do wily manually, then once it's all in wily sync the whole lot back to vivid.
[18:29] <sil2100> rvr: you still around? :)
[18:29] <anpok_> robru: why manually?
[18:30] <robru> anpok_: I don't understand your question. what are you trying to do? what are you expecting to happen?
[18:31] <anpok_> robru: i want to release a new mir version to both vivid+overlay and wily + all reverse dependencies that would otherwise break because of ABI breaks in libmirclien
[18:31] <anpok_> t
[18:31] <robru> anpok_: ok so when you put "glmark2 xorg-server gtk+3.0" in column G, it means "I'm going to build these packages myself manually then upload them into the PPA myself manually."
[18:31] <anpok_> so we added xorg-server, and two different versions of gtk+ and glmark to the silo
[18:32] <anpok_> robru: yes
[18:32] <robru> anpok_: ok so in a dual silo, that behavior is undefined, because the train isn't able to do vivid copies of manually-created packages.
[18:32] <anpok_> but well we only uploaded change files and the ppa did the building (i know glmark2 currenty fails for vivid but will be updated)
[18:32] <robru> anpok_: the train can only make vivid copies of packages that it created
[18:32] <rvr> sil2100: Still around
[18:33] <robru> anpok_: what you need to do is make the silo just a wily silo, then those manual sources will work. then release to wily. Once the wily release is complete, you can make a second silo that syncs everything back to vivid.
[18:33] <sil2100> rvr: can I ask you to quickly check if the -es translations are ok? I'll be pushing the -es langpack to the silo, want someone to double-confirm if I didn't mess anything up
[18:34] <rvr> sil2100: Do you want me to check the langpack file?
[18:34] <rvr> Ah, in a silo
[18:34] <rvr> sil2100: Ok
[18:34] <sil2100> rvr: yes :) It's building right now, but it should be real fast
[18:35] <sil2100> I have all langpacks ready for upload, but I don't want to upload them if I messed it up
[18:37] <anpok_> robru: hmm ok .. odd .. I thought it would work, since the packages were correctly sorted according to the series.. when reconfiguring that to be only wily .. what will happen with the packages already uploaded?
[18:45] <robru> anpok_: oh I'll have to delete the vivid packages myself
[18:46] <sil2100> rvr: waiting for the binaries to get published
[18:46] <robru> anpok_: yeah there's no technical reason that it couldn't be made to work the way you expect, it's just that when I implemented dual landings I didn't anticipate this use case and so unfortunately the behavior is literally just undefined (if the prepare job allowed configuring a silo this way, the build job would just explode because it would try to make a
[18:46] <robru> vivid copy of a manual package that it doesn't have access to at the time that it needs it)
[18:49] <anpok_> hm ok .. I thought it was a landing problem and not a package building problem (because the building part worked fine so far..)
[18:54] <sil2100> rvr: grrr, this is taking ages ;/
[18:58] <sil2100> rvr: could you check https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-002/ and its -es langpack?
[18:58] <rvr> sil2100: Silo ready?
[18:59] <sil2100> rvr: the -es package in it, yes - I didn't upload the rest
[18:59] <sil2100> (since there's a lot more)
[18:59] <rvr> Installing
[18:59] <sil2100> Thank you!
[19:04] <pmcgowan> alecu, pstolowski ok my mistake but the qa board said 42 passed
[19:05] <alecu> pmcgowan: yes, it passed the QA checks, but failed when landing of the image
[19:05] <pmcgowan> oh I see it passed but build failed
[19:05] <pmcgowan> ok
[19:06] <alecu> pmcgowan: only one test in arm64 was failing, on armhf it worked ok
[19:06] <pstolowski> pmcgowan, arm64 build failed but for some reason that didn't stop it from getting into proposed pocket (where it got blocked), that's why it got under our radar till today afternoon
[19:06] <pmcgowan> alecu, jeesh
[19:07] <pstolowski> s/it got/it didn't/
[19:07] <pmcgowan> pstolowski, need help or is it sorted?
[19:07] <pstolowski> pmcgowan, sil2100 helped me already, waiting for build to finish, thanks
[19:08] <alecu> pstolowski: thanks to you for staying so late! :-)
[19:08] <pstolowski> np
[19:10] <sil2100> Fixes keep coming ;)
[19:12] <pstolowski> sil2100, alecu it has been built! giving it a quick test on the phone
[19:12] <sil2100> pstolowski: \o/
[19:15] <pstolowski> sil2100, is it possible that part-broken silo got already landed into the overlay ppa?
[19:16] <pstolowski> sil2100, i mean not broken, but with arm64 package missing
[19:17] <pstolowski> sil2100, this is what i mean http://pastebin.ubuntu.com/11843330/
[19:18] <sil2100> pstolowski: yeah, it most probably did
[19:18] <sil2100> But no worries
[19:19] <pstolowski> sil2100, ok, cool. so silo42 is good now. as said before, it has been tested by qa already and only rebuilt with the failing arm64 test temporarily disabled
[19:19] <pstolowski> alecu ^
[19:19] <sil2100> jibel: so I suppose you're ok with getting that published, right?
[19:21] <alecu> pstolowski: you rock, thanks a lot!
[19:22] <sil2100> Anyway, I suppose I'll just publish it
[19:31] <sil2100> rvr: any luck?
[19:31] <rvr> sil2100: On it
[19:33] <cwayne> sil2100: ping
[19:36] <sil2100> cwayne: pong
[19:37] <cwayne> sil2100: it seems some badness has made it's way into the custom tarball :/  when is the final RC image being built? is there time for a custom re-spin?
[19:37] <sil2100> cwayne: uh, what kind of badness?
[19:38] <cwayne> sil2100: a nearby scope update that shouldn't have gone in
[19:38] <sil2100> Ouch!
[19:38] <rvr> sil2100: We have somethings still untranslated, but everything else looks fine
[19:38] <rvr> sil2100: It doesn't break anything :)
[19:38] <sil2100> rvr: ok, phew... thanks ;)
[19:38] <sil2100> Let me upload the rest
[19:39] <sil2100> cwayne: hm, ok, so the custom re-spin would only revert that one scope to a previous version, right?
[19:39] <cwayne> sil2100: i'd need to double-check with kyle and penk (since I don't own it anymore, I don't want to actually make the decision)
[19:40] <sil2100> We can upload it tomorrow I suppose then, we just need to make sure to inform the QA team so that they don't waste time on testing that
[19:40] <cwayne> righto, I'll sync up with penk tonight
[19:40] <sil2100> jibel, rvr, davmor2: ^ we'll need a custom tarball upload tomorrow still
[19:42] <davmor2> sil2100: yes for the fix to CTR if nothing else I think cwayne should be made to fix it myself ;)
[19:48] <cwayne> davmor2: :)
[19:50] <pmcgowan> sil2100, did silo 42 make it ok this time
[19:50] <pmcgowan> sil2100, and it looks like 53 can publish
[19:51] <sil2100> pmcgowan: not sure about 42 yet, it's fine on the overlay but still don't see it on wily migration
[19:52] <sil2100> pmcgowan: publishing! Was busy with langpacks
[19:52] <sil2100> Argh
[19:52] <sil2100> Unbuilt revisions again
[19:52] <sil2100> jgdx: ping
[19:53] <sil2100> jgdx: I think revision 1462 didn't get built...
[19:53] <sil2100> Please make sure not to push any new commits without rebuilding the silo
[19:54] <sil2100> pmcgowan: without jgdx not sure if we can land it ;/
[19:56] <sil2100> grrr
[19:58] <jgdx> sil2100, here
[19:59] <sil2100> jgdx: hey! Do you remember if 1462 was built in the silo for merge https://code.launchpad.net/~jonas-drange/ubuntu-system-settings/handle-ssid-bssid/+merge/263664 ?
[19:59] <sil2100> I think only 1461 was there then
[19:59] <sil2100> Is that commit required?
[20:00] <jgdx> sil2100, when was the silo built?
[20:00]  * jgdx checks
[20:01] <jgdx> sil2100, built today and that push was done yesterday it seems
[20:01] <sil2100> jgdx: I just checked in the train and 1462 was indeed not built
[20:01] <sil2100> Branched 1461 revisions. <- this was built
[20:01] <sil2100> Is 1462 necessary?
[20:01] <jgdx> yes
[20:02] <sil2100> Damn, then we need to rebuild it and get a re-test
[20:02] <sil2100> Thought it wasn't, since kenvandine approved it without it
[20:03] <sil2100> pmcgowan: is silo 53 an OTA-5 blocker?
[20:03] <pmcgowan> sil2100, well, its one of the few new features
[20:04] <sil2100> jgdx: will you be re-building the silo then?
[20:04] <jdstrand> pmcgowan: hey, so apparmor-easyprof-ubuntu is tested by me and QA, but it is still shows 'QA needs sign off'
[20:04] <jgdx> sil2100, yes
[20:04] <pmcgowan> jgdx, what does 1462 fix?
[20:04] <jgdx> kenvandine, could you approve 1462 in the handle ssid branch?
[20:04] <pmcgowan> jdstrand, someone goofed and did not set the approved flag
[20:04] <pmcgowan> sil2100, ^^
[20:05] <jdstrand> sil2100: you can see backscroll conversation between me and rvr if you need context
[20:05] <jgdx> pmcgowan, dispatched urls are not handled properly if USS is running in 1461, 1462 fixes that.
[20:05] <jgdx> sil2100, maybe davmor2 can chime in
[20:06] <jdstrand> sil2100: (this is line 82 in the spreadsheet)
[20:06] <sil2100> jdstrand: oh, a silo for release?
[20:06] <jdstrand> sil2100: for vivid stable-phone-overlay, yes
[20:07] <sil2100> Phew, I aborted it on time
[20:07] <popey> pmcgowan: ahayzen is in university halls and is trying to get the WPA stuff working, is that dependant on silo 53?
[20:07] <sil2100> SOmeone miss-assigned the silo, it wasn't targetting the overlay
[20:07] <jgdx> sil2100, [1] is building 1462. [1] https://ci-train.ubuntu.com/job/ubuntu-landing-053-1-build/7/console
[20:07] <jdstrand> sil2100: sil2100 oh, that would've been me :(
[20:07] <popey> He's a good person to test this stuff, his university network is one that we can't connect to
[20:07] <pmcgowan> popey, yes
[20:07] <popey> ok
[20:08] <sil2100> No worries, reconfiguring and republishing ;)
[20:08] <jdstrand> sil2100: this was the first time I did a silo assignement. I guess I messed up
[20:08] <sil2100> It's easy to forget, we do that mistake all the time
[20:08] <sil2100> jgdx: \o/
[20:09] <jdstrand> sil2100: I'm not sure what I should've done differently...
[20:10] <jdstrand> sil2100: I chose ubuntu/vivid from the dropdown, highlighted the fow, then used Landing tools.
[20:10] <sil2100> jdstrand: there's column 'L' that needs to be changed to the overlay-ppa from the dropdown
[20:10] <sil2100> jdstrand: since otherwise it targets normal vivid
[20:10] <sil2100> :)
[20:10] <jdstrand> oh, yes, I didn't do anything with that
[20:10]  * jdstrand takes a note
[20:10] <jdstrand> I see, cool
[20:11] <sil2100> Silo published o/
[20:12] <jdstrand> sil2100: thanks!
[20:13] <sil2100> You're welcome
[20:13] <robru> wut
[20:14] <sil2100> It was switched to 'testing done' after publishing, hah
[20:16] <sil2100> Language packs published
[20:16] <jgdx> sil2100, I'm on telegram 2-3 more hours if anything pops up.
[20:16] <sil2100> (might still need some work)
[20:16] <sil2100> jgdx: will you need to test it after it's done?
[20:16] <sil2100> Or can it go straight to QA?
[20:17] <jgdx> I can test some of it, but I'm not really remotely close to a wpa network
[20:17] <sil2100> pmcgowan: hm, not sure what to do here
[20:17] <jgdx> sil2100, wpa-ep I mean
[20:18] <jgdx> sil2100, I can test system settings r1462, so I guess the answer is yes
[20:18] <pmcgowan> popey, is ahayzen able to test the silo?
[20:28] <sil2100> So we're waiting for 36 and 53 then
[20:28] <sil2100> I go now grab some food, will be back in a bit
[20:29] <sil2100> Don't want to be eating at midnight
[20:29] <ogra_> bad karma ?
[20:33] <davmor2> sil2100 whats up
[20:34] <davmor2> sil2100 I marked 53 passed if it is jgdx s
[20:34] <om26er> mzanetti, so unity8 feels good to me, I tried to play a few games, tried multiple app. the arale's screen have all of a sudden become very useful.
[20:34] <mzanetti> om26er, nice! thanks
[20:35] <om26er> mzanetti, should we wait for the device tarball or is it fine to approve this landing now ?
[20:35] <ogra_> mzanetti, does that fix the crashes on boot ?
[20:35] <popey> pmcgowan: he went for dinner, should be back later
[20:36] <jgdx> davmor2, most recent silo 53 build did not include the most recent revision for some reason.
[20:37] <davmor2> jgdx so needs a retest
[20:37] <jgdx> davmor2, yes, but ahayzen's apparently close to a wpa2 net
[20:37] <jgdx> wpa2ep
[20:38] <mzanetti> om26er, I think we can land... even in the unlikely event the tarball wouldn't make it, this branch should not really change how it looks when you still run it with the other GRID_UNIT_SIZE.
[20:38] <ogra_> ah, not the crashes ...
[20:39] <pmcgowan> om26er, arale's screen have all of a sudden become very useful. thats good to hear
[20:39] <ogra_> yeah
[20:40] <ogra_> that took a while :)
[20:40] <om26er> ogra_, I remember you were the first to mention that issue a looong time ago ;)
[20:40] <ogra_> yeah, and i had to battle :)
[20:41] <davmor2> jgdx okay if you need my setup just ping I'll be back home soon
[20:41] <sil2100> Please approve the silo, I'll release it ;)
[20:44] <om26er> mzanetti, I don't see a line for silo 36 on the spreadsheet, though.
[20:46] <jibel> om26er, row 85
[20:48] <om26er> jibel, oh, my bad.
[20:48] <jibel> sil2100, ^
[21:09] <sil2100> o/
[21:11] <sil2100> davmor2: silo 53 is built now it seems, do you need jgdx to first test it?
[21:11] <sil2100> ogra_: since slangasek does not seem to be around, could you maybe review/merge https://code.launchpad.net/~sil2100/livecd-rootfs/remove_youtube_scope/+merge/263350 ?
[21:12] <sil2100> ogra_: does livecd-rootfs need to be released somehow afterwards?
[21:17] <sil2100> davmor2: ^ silo 53 just for you <3
[21:19] <ahayzen> popey, i'm back :-) what am i breaking?
[21:19] <popey> \o/
[21:19] <popey> aww pmcgowan left
[21:19] <popey> jibel: need someone to help test silo 53? ahayzen is near an affected network
[21:19] <sil2100> I think we would appreciate some help here
[21:20] <sil2100> But probably jgdx, jibel or davmor2 would need to be around to give details
[21:26] <jibel> sil2100, popey any help is appreciated but davmor2 knows the details
[21:27] <jibel> sil2100, can you build an image once unity8 lands?
[21:28] <AlbertA> cihelp: hi, who can I ask to modify the mir-clang-wily-amd64-build job?
[21:28] <AlbertA> cihelp:  we essentially need to add an extra build that has Thread Sanitizer enabled
[21:29] <robru> cihelp: anybody familiar with this traceback from jenkins charm? https://www.irccloud.com/pastebin/DeGeR0u2/
[21:30] <ahayzen> jibel, hey i've done $ citrain device-upgrade 053 <passcode> ubuntu .. but i didn't see indicator-network of system-settings in the update was that the right command?
[21:32] <fginther> AlbertA, I can take a look
[21:34] <fginther> robru, can't say I've seen that one, is the volume actually attached to the instance
[21:34] <robru> fginther: no, that's the trick, this error happens when mounting the volume
[21:35] <jgdx> ahayzen, is the citrain list in /etc/apt/sources.list.d ?
[21:35] <fginther> robru, you mean it's thrown by the manifest "volumes" command?
[21:35] <ahayzen> jgdx, i'll have a look, i just did this as well http://pastebin.ubuntu.com/11844053/
[21:36] <ahayzen> jgdx, "ci-train-ppa-service-ubuntu-landing-053-vivid.list" is there
[21:36] <robru> fginther: it's thrown by the config-changed hook shortly after setting the volume-map option on the charm.
[21:36] <jgdx> ahayzen, doing the same right now. Let me have a look
[21:36] <ahayzen> jgdx, thanks
[21:36] <fginther> robru, ok, but something else has to do a "nova volume-attach" command to actually the nova volume to the instance, juju can't do that
[21:37] <robru> fginther: right, so there's volumeconfig step to attach the volume, and then there's a juju deploy step to set the volume-map
[21:37] <robru> fginther: and then after that it explodes
[21:38] <jgdx> ahayzen, sudo apt-get install ubuntu-system-settings=0.3+15.04.20150708-0ubuntu1 indicator-network=0.5.1+15.04.20150708.1-0ubuntu1
[21:38] <ahayzen> jgdx, The following packages have unmet dependencies:
[21:38] <ahayzen>  ubuntu-system-settings : Depends: libsystemsettings1 (= 0.3+15.04.20150708-0ubuntu1) but 0.3+15.04.20150703-0ubuntu1 is to be installed
[21:38] <ahayzen> E: Unable to correct problems, you have held broken packages.
[21:39] <fginther> robru, can you verify that the volume is attached? perhaps that step failed horribly
[21:39] <jibel> ahayzen, not sure what citrain device-upgrade does exactly but for me it crashes http://paste.ubuntu.com/11844083/
[21:39] <jgdx> ahayzen, sorry, do $ … {ubuntu-system-settings,libsystemsettings1}=0.3+15.04.20150708-0ubuntu1
[21:39] <jgdx> as well as the indicator
[21:39] <robru> fginther: yeah, it's not attached, that is the problem.
[21:39] <sil2100> jibel: I can, but aren't we waiting for silo 53?
[21:40] <jgdx> jibel, no network on the phone maybe?
[21:40] <davmor2> jibel, sil2100 okay I'm back home
[21:40] <fginther> AlbertA, so you want to do 2 builds with mir-clang-wily-amd64-build? Continue to do the current build and then repeat it with an additional option?
[21:40] <ahayzen> jgdx, that worked \o/ rebooting
[21:40] <jgdx> ahayzen, \o/
[21:40] <AlbertA> fginther: yeah, basically "CXX=/usr/bin/clang++ CC=/usr/bin/clang cmake -DCMAKE_BUILD_TYPE=ThreadSanitizer ../"
[21:41] <AlbertA> fginther: then do the build and run the tests "ctest -V"
[21:41] <sil2100> Damn, there's no one to merge my livecd-rootfs merge, slangasek didn't do it - I hope we won't have a duplicate scope on the phone
[21:42] <AlbertA> fginther: so yeah " normal build - run tests - TSAN build - run tests"
[21:42] <davmor2> jibel, sil2100, jgdx: flashing new image will add silo after that
[21:43] <sil2100> jibel, davmor2: unity8 is on the overlay already, but I was waiting with image builds for silo 53
[21:43] <jgdx> davmor2, thanks. you'll need $ sudo apt-get install {ubuntu-system-settings,libsystemsettings1}=0.3+15.04.20150708-0ubuntu1 indicator-network=0.5.1+15.04.20150708.1-0ubuntu1
[21:43] <sil2100> davmor2: how much do you think you'll need to test silo 53?
[21:43] <jibel> davmor2, how long do you think it'll take?
[21:44] <jibel> :)
[21:44] <davmor2> once the image is flash and app installed etc 20 minutes if it is only going over the bits that change 2-3 hours if it is the whole test plan
[21:45]  * sil2100 opts for the 20 minute version
[21:45] <sil2100> ;p
[21:45] <fginther> AlbertA, is a 'make clean' between the two builds sufficient?
[21:45] <jibel> jgdx, indeed, there is no network on the phone but that's what phablet-network is supposed to configure, isn't it?
[21:45] <jgdx> jibel, never has for me :s
[21:46]  * ahayzen wonders why some of the eduroam guides say to use TunneledTLS and others to use PEAP ..both with MSCHAPv2
[21:46] <jibel> jgdx, for me neither, that's why I add silos  manually :)
[21:46] <AlbertA> fginther: ummm I dunno let me try locally here
[21:46] <davmor2> image flashed
[21:48] <ahayzen> jibel, jgdx, so copying the settings i have on my laptop (which connects) causes it just to sit there spinning ... note that when i select the CA certificate it still says "None" though
[21:48] <ahayzen> and the last thing related to NM i can see is "<info> Activation (wlan0) Stage 4 of 5 (IPv4 Configure Timeout) complete."
[21:49] <ahayzen> (this was with PEAP+MSCHAPV2, possibly a CA cert and a username and password specified)
[21:49] <jgdx> ahayzen, eduroam?
[21:49] <ahayzen> jgdx, yeah
[21:49] <jgdx> ahayzen, so that took a while for me.. using a cert
[21:49] <jgdx> but eventually it worked
[21:50] <ahayzen> define "a while"
[21:50] <jibel> jgdx, apparently phablet-network if there is a vpn up on the wireless interface
[21:50] <jibel> phablet-network fails*
[21:50] <ahayzen> but the UI shows "None" surely that should be fixed as i selected the cert and clicked save
[21:51] <jgdx> ahayzen, it's still in the list though?
[21:51] <ahayzen> erm i can't see the UI is locked due to it still trying to connect
[21:51] <ahayzen> let me try again
[21:51] <AlbertA> fginther: no apparently not
[21:51] <fginther> AlbertA, ack
[21:52] <ahayzen> jgdx, in the list i have "None" and "Choose..."
[21:52] <jibel> davmor2, the 20 minutes version of the test plan looks good given that you already covered the test plan 3h ago
[21:53] <davmor2> jibel: that's what I thought and we'll cover it again tomorrow
[21:54] <jgdx> ahayzen, that means the cert import failed..
[21:54] <ahayzen> jgdx, ah ok, is there a log i can look at?
[21:54] <fginther> AlbertA, is the thread build of use if the first build fails?
[21:55] <AlbertA> fginther: I would say no
[21:55] <fginther> AlbertA, ok, thanks
[21:55] <AlbertA> fginther: but yes if only the test fails
[21:56] <jgdx> ahayzen, .cache/upstart/application-legacy-ubuntu-system-settings-.log
[21:56] <ahayzen> jgdx, http://pastebin.ubuntu.com/11844170/
[21:57] <jgdx> ahayzen, aah I mean syslog
[21:57] <ahayzen> ah ;-)
[21:58] <jibel> sil2100, you'll still be around to build an image once silo 53 is published?
[21:58] <jgdx> ahayzen, did you try a second import?
[21:58] <davmor2> jgdx, jibel, sil2100: I have a network connection
[21:58] <ahayzen> jgdx, yeah
[21:58] <jgdx> davmor2, thanks!
[21:58] <ahayzen> jgdx, and literally nothing appeared in the /var/log/syslog only powerd stuff
[21:59] <davmor2> jgdx: where can the indicator read in from? does the cert need to be in a certain directory?
[22:00] <ahayzen> jgdx, this is the certificate i have http://obis.brookes.ac.uk/wireless/certs/AddTrustExternalCARoot.cer
[22:00] <jgdx> davmor2, any file providing content hub peer
[22:01] <ahayzen> jgdx, ooooo i want the other one? http://obis.brookes.ac.uk/wireless/certs/AddTrustExternalCARoot.crt
[22:01] <ahayzen> (that one appears in the list when i import)
[22:01] <jgdx> ahayzen, \o/
[22:01] <ahayzen> now to see if it connects
[22:02] <jgdx> ahayzen, when I tested eduroam I downloaded a text file from eduroam's pages.
[22:02] <jgdx> BEING CERTIFICATE and so on
[22:03] <ahayzen> jgdx, we have like a million tutorials http://obis.brookes.ac.uk/wireless/wireless_setup_Linux.html or a script https://cat.eduroam.org/user/API.php?action=downloadInstaller&lang=en&id=linux&profile=608
[22:03] <robru> fginther: thanks a bunch, it seems to work if I just call 'nova volume-attach ...' before setting the volume-map. I have no idea why mojo failed to do this for me (or how it ever worked before)
[22:04] <ahayzen> jgdx, ugh now its just asking me for my password over and over again
[22:04] <jgdx> ahayzen, did you use 'remember password'?
[22:04] <ahayzen> erm
[22:04] <davmor2> ahayzen: and did you type it in correctly ;)
[22:04] <ahayzen> just trying remember password :-)
[22:05] <ahayzen> ugh still kicks me out
[22:05] <fginther> robru, glad it's working. The only thing I can suggest checking is to make sure the volumeconfig file has the right id in it (should match the volume id being passed in the volume-map option)
[22:05] <fginther> robru, if the volume is mapped to another instance, it would fail, but that doesn't sound like your problem
[22:05] <davmor2> ahayzen: forget the network and try it again and ignore the password popup it is nothing to do with the part you are trying to use
[22:06] <robru> fginther: yep, quadruple-checked that. it's as though volumeconfig step isn't running but it's clearly there in the manifest and also shown in the mojo log. total mystery.
[22:06] <ahayzen> davmor2, ok :-)
[22:06]  * fginther is stumped
[22:07] <davmor2> ahayzen: I think you are hitting this https://bugs.launchpad.net/bugs/1472734
[22:07] <sil2100> jibel: sure
[22:09] <ahayzen> appears to be stuck at "Activation (wlan0) Stage 4 of 5 (IPv4 Configure Timeout) complete." again .. i'll wait and see what happens
[22:10] <jgdx> sil2100, ack from me on silo 53. Do I mark it as such, overwriting the prev ack?
[22:11] <ahayzen> jgdx, thats the log up to the point its stuck at http://pastebin.ubuntu.com/11844283/ i've omitted my username/password
[22:11] <sil2100> jgdx: you can leave it as it is :)
[22:11] <jgdx> sil2100, okay :)
[22:13] <jgdx> ahayzen, you're able to connect to this network using an ubuntu desktop?
[22:13] <ahayzen> jgdx, yep :-)
[22:13] <jgdx> ahayzen, okay. Well, it seems auth is good, but dhcp fails? I do believe that's beyond the scope of this silo, so not sure what to do.
[22:14] <ahayzen> :-/
[22:14] <jgdx> ahayzen, we could compare /etc/NetworkManager/system-connections/eduroam from both the phone and desktop and see if there are differences
[22:14] <ahayzen> jgdx, ok :-)
[22:15] <jgdx> ahayzen, there will be sensitive things in there
[22:15] <ahayzen> jgdx, oh my desktop one uses the .cer instead of the .crt
[22:15] <jgdx> ahayzen, is that required though? Could you try making a connection without once?
[22:16] <ahayzen> i'm not sure it is as i know friends who haven't used the cert
[22:16]  * ahayzen tries
[22:16] <davmor2> ahayzen: try renaming the cer one to crt after backing them all up obviously ;)
[22:17] <davmor2> ahayzen: and then connect using that one :)
[22:17] <davmor2> jgdx: does it allow addition of cer's or is it strict on crt?
[22:18] <jgdx> davmor2, I'm unsure, I would have to contact the developer.
[22:18] <ahayzen> otherwise the only difference i can visually see is the the desktop has password-flags=1 and the phone has password=<password>  ..and the phone has the addition of auth-alg=open under [wifi-security]
[22:19] <robru> sil2100: are you still publishing stuff or do you want me to do this one?
[22:20] <sil2100> Still on a publishing roll
[22:20] <ahayzen> jgdx, without a certificate i think it may have worked :-D let me double check
[22:20] <sil2100> Just pressed the button on that one
[22:20] <robru> sil2100: sweet. I'm on a "get bileto ready for production" roll ;-)
[22:20] <sil2100> ;)
[22:20] <sil2100> !
[22:20] <jgdx> ahayzen, /me clenches
[22:20] <sil2100> I like the sound of that
[22:21] <sil2100> Ok, looks like the only thing left is silo 53
[22:22] <ahayzen> jgdx, i think its working :-D inet addr:<IP_ADDRESS> which is not on my own WiFi \o/
[22:22] <veebers> mzanetti: ^^ that's the fix for autopilot being released :-) Thanks for the help testing (and alesage too)
[22:22] <davmor2> sil2100, jibel, jgdx: okay everything is looking good here.  I'm happy to pass it
[22:22] <jgdx> ahayzen, woo
[22:22] <sil2100> I see ahayzen also seems to like it
[22:22] <mzanetti> nice. thanks
[22:22] <popey> \o/
[22:22] <sil2100> Thanks everyone!
[22:22] <ahayzen> jgdx, wonder why you optionally need the cert lol
[22:22] <jgdx> ahayzen, I'll file a bug for the cert stuff..
[22:22] <ahayzen> jgdx, thanks
[22:22] <jgdx> ahayzen, added security
[22:22] <sil2100> Ok, publishing it
[22:22] <jgdx> for whistle blowers and such :p
[22:23] <ahayzen> ah
[22:23] <ahayzen> whistle blowers going over a govenment provided internet...lol
[22:23] <jibel> davmor2, wonderful, thanks!
[22:23] <jibel> ahayzen, thanks for your help!
[22:23] <ahayzen> anyway great work on this guys i can now use my phone on campus \o/
[22:23] <jgdx> ahayzen, oh snap
[22:23] <jgdx> ahayzen, thanks for the help!
[22:24] <ahayzen> no problem, so happy i can actually use it rather than a 2g connection lol
[22:25] <davmor2> ahayzen: don't live in america then live where the 4g works ;)
[22:25] <davmor2> okay I'm really going back to EOD now ;)
[22:25] <ahayzen> davmor2, there is 4g in town...just my campus is out of town :'( in the sticks of oxfordshire
[22:26] <davmor2> ahayzen: oh that sucks
[22:26] <davmor2> ahayzen: try a 3 sim
[22:26] <sil2100> Published, now I wait for the binaries to fully appear on the overlay and I kick a new image
[22:26] <sil2100> Phew, this was a long day
[22:26] <davmor2> ahayzen: they seem to have better coverage daft as it sounds
[22:26] <ahayzen> davmor2, either you get good signal in town or bad signal out of town your choice lol O2 good in and EE good out lol
[22:27] <davmor2> anyway night all o/
[22:27] <ahayzen> night o/
[22:27] <sil2100> davmor2: goodnight!
[22:28] <jgdx> ahayzen, davmor2, sil2100: filed for the certificate bug https://bugs.launchpad.net/canonical-devices-system-image/+bug/1472805
[22:28] <ahayzen> jgdx, thanks
[22:28] <jgdx> ahayzen, were you using a certificate on your desktop?
[22:29] <ahayzen> jgdx, yeah the .cer one
[22:29] <jgdx> ahayzen, got it. Thanks
[22:36] <sil2100> jibel, davmor2, ToyKeeper: kicking a new image now o/
[22:36] <sil2100> jibel, davmor2, ToyKeeper: this will be our first promotion candidate
[22:36] <ToyKeeper> sil2100: Woot!
[22:36] <sil2100> Disabling cronjob too
[22:36] <ToyKeeper> I've been waiting for it.
[22:37] <ToyKeeper> (well, doing some development while waiting)
[22:37] <ToyKeeper> sil2100: It'll be ... image 53, I think?
[22:37] <sil2100> For the arale?
[22:38] <jibel> ToyKeeper, arale #53 and krillin #62
[22:38] <ToyKeeper> Right, thanks.  :)
[22:38] <sil2100> Yes
[22:38] <sil2100> Ok, cronjob disabled, image building
[22:38] <sil2100> Time for a shower and off to sleep
[22:39] <sil2100> Thanks for all the hard work everyone, good luck to the rest :)
[22:39] <sil2100> Goodnight!
[22:43] <veebers> trainguards I seen an error on the spreadsheet for my silo, has this affected the actual release of the package or just merging the branch?
[22:43] <robru> veebers: what row?
[22:44] <veebers> robru: 81
[22:45] <robru> veebers: yes this is a failure of merging. so autopilot published fine
[22:45] <robru> veebers: you need to check the ownership of lp:autopilot/overlay. Most likely it's owned by a person instead of a team, or it's owned by a wrong team that the train isn't a member of
[22:46] <veebers> robru: ah I see, I'll check now.
[22:46] <robru> veebers: indeed you need to add ~ci-train-bot to https://launchpad.net/~canonical-platform-qa/+members#active for this to work
[22:46] <veebers> robru: owner is "Canonical Platform QA Team" I feel that perhaps the train should be a member of rthtat?
[22:46] <veebers> robru: heh coolio, thanks doing now
[22:47] <robru> veebers: train should try again shortly and take care of itself once permissions are fixed
[22:47] <veebers> robru: nice, thanks :-)
[22:47] <robru> veebers: you're welcome
[22:48] <robru> veebers: oh and you can delete ~ps-jenkins bot from that team, we don't use that one anymore.
[22:50] <veebers> robru: ack thanks, trying to get an admin to action that now


[15:32] <Rockj> btw, is it possible to request a rename of username on launchpad? I dont like that they added a "-" in my first name when I don't use a "-" in my firstname :/
[15:39] <Rockj> The name 'launchpad-intellij-tasks-provider' has been blocked by the Launchpad administrators. Contact Launchpad Support if you want to use this name.
[15:39] <Rockj> meh :(
[15:42] <Rockj> Will I be able to find administrators in this IRC channel or do I have to send an email?
[15:45] <maxb> Rockj: I believe you can rename your user id yourself
[15:46] <maxb> Meanwhile, project names starting with certain key names are blocked from standard registration, file a question at https://answers.launchpad.net/launchpad/+addquestion to request renaming of an existing project to a restricted name
[15:46] <Rockj> nope, not on my profile. I can edit email etc etc
[15:46] <maxb> hmm
[15:46] <maxb> what's your lp id?
[15:46] <Rockj> roy-sindre
[15:46] <Rockj> https://launchpad.net/~roy-sindre
[15:47] <maxb> ok, I've removed the hyphen for you
[15:47] <maxb> perhaps policies have changed at some point, I was sure that was self service at one point
[15:48] <Rockj> aha, I think I just signed it with my openid sometime and it autogenerated the username
[15:48] <Rockj> normally use norangshol, roysindre, norrs or Rockj :-)
[15:49] <maxb> yes, I ended up being 'maxb1' originally until I found how to change tht
[15:49] <Rockj> maxb: ok, so I'll just create a project name without launchpad in it I assume and then request a name change on it?
[15:50] <maxb> I think lp- as a prefix is unrestricted, you could start with that
[15:50] <maxb> yes
[15:50] <Rockj> maxb: and next time I should have just said I wanted 'norangshol' as username, but roysindre is fine. and Thanks :)
[15:50] <maxb> norangshol is free, so it's no trouble to change it again
[15:51] <maxb> changed
[15:51] <Rockj> Thanks again.
[16:31] <Rockj> btw is there any issue including the launchpad logo in my project which is under Apache2 license? It's simply a plugin to list bugs from launchpad in my IDE
[16:37] <Rockj> and should the apache 2 copyright top line in files say my full name or project name? :]
[23:18] <Bert_2> can I ask questions here about issues I have with the launchpad code ?
[23:21] <dobey> Bert_2: if you're working on launchpad code itself, then #launchpad-dev might be a better place for that
[23:22] <Bert_2> dobey: thx


[00:10] <mwhudson> teward: no a native package means patches are not applied
[00:11] <mwhudson> (not that i've attempted to SRU a native package with a debian/patches directory or anything embarassing like that)
[00:12] <mwhudson> and the mechanism for making changes is ... making changes
[00:12] <mwhudson> if that's not appropriate it probably shouldn't be a native package i guess
[04:43] <tjaalton> RAOF: thanks, I'll clean it up
[04:52] <tjaalton> meh, I'll just let intel split ipp in a public repo first
[04:52] <tjaalton> there's no way to download ipp anywhere without filling a form
[04:54] <RAOF> Oh, really? WTF?
[04:55] <RAOF> Oh, wow. Yeah.
[04:55] <tjaalton> I'll try stripping it off, only used for some sw fallback
[04:55] <RAOF> Good hustle, Intel.
[04:56] <tjaalton> and let them know about it
[05:17] <JZA> hi got a question about how to mantain a package on launchpad
[05:17] <JZA> currently there is a team account with a package, but I want to get a testing branch from my user
[05:17] <JZA> how do I go about that
[07:16] <tjaalton> RAOF: oh well, can't build it without embedded ipp or gtest. I'll just wait for them to fix it
[07:17] <lag> Hmm ... not sure my messages went through - apologies for the churn if they did:
[07:18] <lag> Does anyone know how to tell the Ubuntu Installer to install additional modules into the rootfs?
[07:18] <lag> s/modules/kernel modules/
[07:18] <lag> I guess we could hack initramfs-tools.deb to include them in the '/etc/initramfs-tools/modules' template, but is there a better/proper way to do this?
[07:21] <RAOF> tjaalton: ipp is not a (strong) blocker, but it should really use the perfectly sensible copy of googletest we have.
[07:21] <tjaalton> or disable tests
[07:22] <tjaalton> anyway, filed tickets upstream
[08:07] <lag> xnox: mwhudson: FYI --^
[08:19] <dupondje> Its to late in the release schedule for merges? Or are some still accepted?
[08:20] <dupondje> mwhudson: https://merges.ubuntu.com/g/golang-1.12/REPORT
[11:45] <Mirv> Trevinho: thank you so much for continous maintenance of the AppIndicator/KStatusNotifierItem extension!
[11:49] <Trevinho> Mirv: :) well actually I should spend much more time on it as there are various issues I had no time to address yet, but thank you :)
[13:14] <tjaalton> ahasenack: hey, do you have plans to push the samba/talloc etc py3 work to debian?
[13:20] <ahasenack> tjaalton: yep
[13:21] <ahasenack> tjaalton: as soon as I'm done with the disco work, which should be tomorrow
[13:22] <tjaalton> ahasenack: ok cool, for experimental I assume?
[13:22] <ahasenack> that will be up to them
[13:22] <ahasenack> I'm planning on salsa mps
[13:22] <tjaalton> right
[13:22] <ahasenack> (I can't upload to debian myself)
[13:23] <ahasenack> experimental sounds right
[13:28] <coreycb> sil2100: hello, if you have a moment we have swift and nova SRUs in the bionic unapproved queue that we'd like to get going on with testing.
[13:35] <sil2100> coreycb: let me try getting to those after the kernels
[13:35] <sil2100> o/
[13:36] <coreycb> sil2100: thanks!
[13:51] <juliank> What's the status of Kubuntu package management?
[13:51] <juliank> Does it use PackageKit or that QApt thing?
[13:52] <juliank> I'm porting software-properties to PackageKit, but only the GTK+ one so far
[13:53] <juliank> Currently the Qt one is a weird mix of aptdaemon and qapt-batch
[15:34] <teward> mwhudson: just saw your message.  It probably doesn't matter much either way, but iptables-persistent has a liiitle bit of a bug in it - https://bugs.launchpad.net/ubuntu/+source/iptables-persistent/+bug/1820144 - so i was wondering how best to prep changes for the SRU.  So just changing it directly, then, would be the proper course since its a native package and not a quilt one?
[15:46] <Kiranos> Hi I have an issue, I'm trying to automate the ubuntu 18.04 installation with preseed, this is how partitioning look like: https://pastebin.com/xm6dQiuV
[15:46] <Kiranos> however I get a prompt like this: https://imgur.com/a/W2sj7yu
[15:46] <Kiranos> I'm not sure which option I miss
[15:46] <Kiranos> I look at https://help.ubuntu.com/lts/installation-guide/i386/apbs04.html and seem to follow it
[15:46] <Kiranos> if I just hit enter on that screen all is just continuing and finalizing
[16:55] <sil2100> coreycb: sorry for it to take so long, let me take a look at your SRUs now
[17:34] <cyphermox> Kiranos: your config is not selecting the recipe; or you are not specifying guided_size, up to you ;)
[17:35] <cyphermox> you would need either "d-i partman-auto/choose_recipe select root"
[17:35] <cyphermox> that's if you want preseed to follow exactly your recipe there
[17:36] <cyphermox> Kiranos: or if you want to use the guided partitioning, you'll want to preseed:
[17:37] <cyphermox> d-i partman-auto-lvm/guided_size string "max"
[17:37] <cyphermox> for example
[17:37] <CarlFK> d-i partman-auto-lvm/guided_size string max
[17:37] <CarlFK> before d-i partman-auto/expert_recipe string                           \
[17:40] <sil2100> coreycb: ugh, why is there an UNRELEASED changelog entry in the changelog for swift?
[17:40] <coreycb> sil2100: checking
[17:40] <sil2100> coreycb: if 2.17.0-0ubuntu1.1 was unreleased, I guess it should be included in 2.17.1-0ubuntu1
[17:41] <sil2100> coreycb: could you re-upload with that fixed? Other than that it's good to go
[17:41] <coreycb> sil2100: yeah let me fix that. thanks for catching it.
[17:46] <sil2100> coreycb: give me a sign once you upload, I accepted nova in the meantime
[17:46] <sil2100> I'll reject the old swift
[17:47] <coreycb> sil2100: should be there soon, just uploaded it. thank you.
[17:52] <sil2100> yw! Thanks for reuploading, approved
[18:29] <jdstrand> cjwatson: hey, does debmirror need any special support for cnf? (command-not-found)
[18:30] <jdstrand> cjwatson: I noticed apt-get update errors on disco and it doesn't seem to pull it. I'm going to use --include and see if that helps
[19:08] <cjwatson> jdstrand: it probably will do, yes
[19:18] <jdstrand> cjwatson: I couldn't get that to work. looked at the dep11 handling and can steal code from there. if I get it to work I'll file a bug with patch
[20:10] <mwhudson> dupondje: i should merge golang-1.12 yeah
[20:10] <mwhudson> teward: yes
[20:11] <teward> mwhudson: ack.  I'll take that approach then.
[20:58] <CarlFK> when bionic runs my systemd script, HOME is not set.  disco and stretch it is set.  I can work around this in my script.  Should I file a bug?
[21:21] <rbasak> rharper: FYI, that bcache bug I asked about was apparently a udev bug
[21:30] <rharper> rbasak: thanks; i really looked like a udev issue; I suspected that many other rules could break as wekk
[21:30] <rharper> well
[21:38] <jdstrand> cjwatson: fyi, bug #1821251
[21:38] <jdstrand> cjwatson: patch is attached
[22:56] <xnox> CarlFK, yes, and also describing the sample script, systemd unit, and whether it is installed as user or system wide.
[22:56] <xnox> CarlFK, potentially you might be able to reproduce it with like systemd-run
[22:57] <CarlFK> xnox: is there a package I should file against ?
[22:57] <xnox> CarlFK, $ ubuntu-bug systemd
[22:57] <CarlFK> thanks
[23:06] <CarlFK> is there a "hello systemd" I can use to demo my HOME issue?