[02:10] <imgbot> [03:45] <imgbot> [03:45] <imgbot> [10:16] <Mirv> mandel: 009
[10:16] <mandel> Mirv, loving it!
[10:16] <mandel> Mirv, thx!
[10:17] <Mirv> :)
[10:19] <mandel> Mirv, anyone from QA I can bully to check silo 16? it is just a fix for unit tests, so it has no affect on anything
[10:20] <mandel> Mirv, and all projects that depend on that are failing to build :O
[10:23] <Mirv> mandel: I added a comment on trello, but rv_r davmo_r2 are the ones around right now. the diff does seem to be under "core" directory however? https://ci-train.ubuntu.com/job/ubuntu-landing-016-1-build/lastSuccessfulBuild/artifact/dbus-cpp_content.diff
[10:23] <Mirv> so I believe they will want to at least quickly smoke test it
[10:24] <mandel> Mirv, yes, it is a core feature.. is just that is blocking huge improvements in location-service.. and I think we all want that fixed hehe
[10:25] <Mirv> sure. they have their hands full of all kinds of testing, but I'm sure they'll note the trello comment when considering what to work on next from the train side.
[11:18] <davmor2> Mirv: you're easily irritated that's good to know :D
[11:21] <Mirv> davmor2: rage is my other name
[11:21]  * davmor2 preps a Mirv ping bot
[11:22] <Mirv> I was searching for a word like disrupted but ended up with irritation
[11:22] <davmor2> Mirv: distracted ?
[11:22] <Mirv> or that, yes ! :)
[11:22] <Mirv> so many d-words
[11:23] <Mirv> well actually I'm quite good in focusing and not hearing the background random noises, but constant (coil) whining might be distracting
[11:23] <Mirv> I've always built PCs with silence on mind as well
[11:24] <davmor2> Mirv: you just need to make the music louder ;)
[11:25] <Mirv> I will be extremely irritated though if I don't get my XPS 13 in May
[12:37] <Mirv> and with that we're out of silos
[12:38] <Mirv> 7 in QA queue though
[13:00] <rvr> boiko: ping
[13:01] <boiko> rvr: pong
[13:01] <rvr> boiko: Silo 24
[13:01] <boiko> rvr: yep
[13:01] <rvr> boiko: The test as described passed *but*
[13:01] <rvr> boiko: the problem is that there is no way to return to the waiting call
[13:02] <boiko> rvr: ?
[13:02] <rvr> boiko: https://bugs.launchpad.net/dialer-app/+bug/1443971
[13:02] <rvr> Expected result:
[13:02] <rvr>  - Call with Phone X ended
[13:02] <rvr>  - Call with Phone Y maintained
[13:02] <boiko> rvr: once you hang up the active call, you get automatically to the waiting call, it is just held
[13:03] <boiko> rvr: you have to manually set it as active again
[13:03] <rvr> boiko: I cannot tap anywhere to re-activate the waiting call
[13:03] <rvr> boiko: Well, I can go back and try to tap in the top green menu, but it doesn't do anything
[13:04] <rvr> So the call remains waiting
[13:04] <boiko> rvr: the top green menu shouldn't appear, so the test case is:
[13:05] <boiko> rvr: you get one incoming call, and accept it
[13:06] <boiko> rvr: you get a second call and "hold+answer" it
[13:06] <boiko> rvr: swap the calls
[13:06] <boiko> rvr: press hangup
[13:06] <boiko> rvr: dialer should continue to be on focus and showing only the remaining call
[13:07] <boiko> rvr: if you are getting something different than that we might have a different problem
[13:08] <rvr> boiko: Yes, the problem is that the active call is dropped, and the other call remains in waiting status
[13:08] <boiko> rvr: but that's expected
[13:08] <boiko> rvr: you have to press the "play" button to re-activate it
[13:08] <rvr> But then, there is no way to switch the waiting call to active
[13:08] <rvr> There is no play button when I drop the other call
[13:09] <rvr> The active call screen is shown
[13:09] <rvr> but the status is "waiting"
[13:09] <boiko> rvr: yep, that's ok, all phones do that
[13:09] <boiko> rvr: you have to press "play" to re-activate the call
[13:09] <rvr> I can go back, and then the top screen goes green
[13:10] <rvr> But tapping there doesn't do anything, besides presenting the active call screen
[13:10] <rvr> boiko: What is the play button?
[13:10] <boiko> rvr: let me get a screenshot for you, just a sec
[13:15] <rvr> boiko: Ok, I discovered which button was the play one
[13:15] <boiko> rvr: https://chinstrap.canonical.com/~boiko/livecall_play_button.png
[13:15] <boiko> rvr: :)
[13:15] <rvr> boiko: And it works... but it is confusing
[13:15] <boiko> rvr: well, there is some reasoning for not enabling the background call automatically, I can explain to you later
[13:16] <boiko> rvr: but basically all other phones do it like that
[13:16] <boiko> rvr: so for regular users of the feature, it is common sense
[13:17] <rvr> I see.
[13:17] <rvr> Well, it works as expected then.
[13:18] <rvr> boiko: Approving the silo.
[13:18] <boiko> rvr: great! thanks!
[13:23] <rvr> mandel: ping
[13:38] <pmcgowan> om26er, silo 6 should be unblocked yes?
[13:38] <pmcgowan> sil2100, promotion?
[13:39] <ogra_> pmcgowan, did we hear back yet ?
[13:39] <pmcgowan> we did
[13:39] <pmcgowan> +1
[13:39] <ogra_> nice
[13:40]  * ogra_ digs for the pompoms and waits for sil2100 
[13:43] <Mirv> \o/ fresh update for my soon finally arriving Bq
[13:44] <popey> \o/
[13:45] <om26er> pmcgowan, last I checked jgdx was working on adding tests for that
[13:45] <pmcgowan> om26er, he did yesterday
[13:47] <om26er> pmcgowan, oh ok, I am getting right onto it
[13:53] <popey> it's a shame that we posted https://insights.ubuntu.com/2015/04/16/phone-updates-april/ before the update has actually gone out
[13:55] <sil2100> pmcgowan: hey, as mentioned on the private channel, I read the e-mail but we need to check something first
[13:55] <mandel> rvr, yes!
[13:55] <sil2100> Waiting for slangasek to appear close by to consult it with him
[14:08] <rvr> mandel: Silo 16
[14:08] <mandel> rvr, yes?
[14:14] <rvr> mandel: Already approved!
[14:15] <mandel> rvr, brilliant, thx!
[14:17] <cyphermox> abeato: rsalveti:  ^^ landing-029 is the silo I was talking about, that needs testing. it would be nice if we managed to land this today, given final freeze.
[14:17] <abeato> ok
[14:25] <sil2100> jibel_: do you remember the number of the last promoted image? ;)
[14:25] <sil2100> For krillin
[14:26] <jibel_> sil2100, 270
[14:26] <jibel_> sil2100, previous was 256
[14:26] <sil2100> Excellent
[14:26]  * sil2100 uses jibel_ as a look-up table
[14:26] <sil2100> Sorry about that
[14:28] <kenvandine> vivid silos sure have been busy lately :)
[14:34] <robru> kenvandine: yesterday we had 11 free! it was heavenly, if only for a moment
[14:34] <kenvandine> robru, there is one free, mind if i snag it?
[14:34] <kenvandine> or is there a queue right now :)
[14:34]  * kenvandine doesn't want to cut in line
[14:35] <robru> kenvandine: yeah I don't see anything ahead of you. just don't hog it forever please (no SRUs!)
[14:35]  * ogra_ tries to free up 19 before EOW
[14:36] <robru> ogra_: thanks!
[14:37] <kenvandine> what?
[14:38] <kenvandine> jgdx, oh... seb128's branch was still in that silo?
[14:38] <robru> jgdx: wtf dude... https://code.launchpad.net/~seb128/ubuntu-system-settings/security-focus-correct-entry/+merge/254804 is rejected but the silo went through QA.
[14:38] <abeato> cyphermox, what should I look at especially when testing?
[14:39] <abeato> cyphermox, and with which devices have you tested this already?
[14:39] <kenvandine> robru, it had been approved before, but later rejected because they wanted tests
[14:39] <jgdx> robru, no
[14:39] <robru> kenvandine: if it was rejected why was it submitted for qa?
[14:39] <jgdx> robru, I changed it in the spreadsheet and reconfigured
[14:39] <jgdx> kenvandine, no:)
[14:40] <kenvandine> jgdx, it's still on the spreadsheet
[14:40] <robru> jgdx: well, om26er reviewed your silo... I recommend publishing it and then adding tests later, because if you reject it now you've wasted om26er's time
[14:40] <jgdx> kenvandine, that's not what I am seeing
[14:41] <kenvandine> i see it
[14:41] <jgdx> kenvandine, line 29?
[14:41] <kenvandine> yes
[14:41] <kenvandine> https://code.launchpad.net/~jonas-drange/ubuntu-system-settings/security-focus-correct-entry/+merge/256345 https://code.launchpad.net/~seb128/ubuntu-system-settings/give-focus-to-entry/+merge/252594 https://code.launchpad.net/~seb128/ubuntu-system-settings/battery-focus-refresh/+merge/253854 https://code.launchpad.net/~seb128/ubuntu-system-settings/bluetooth-null-device/+merge/250895
[14:42] <kenvandine> oh
[14:42] <jgdx> yes
[14:42] <kenvandine> that's your branch...
[14:42] <kenvandine> i just saw the same name ;)
[14:42] <jgdx> robru, I changed the MP cell and reconfigured. I did not mean to waste anyone's time.
[14:42] <kenvandine> maybe the reconfigure failed?
[14:42] <jgdx> And according to the landing process doc, I can reconfigure on my own if the MP cell changes
[14:42] <jgdx> I got no error message
[14:43] <robru> jgdx: not sure what you did, but the reconfigure didn't take effect. silo still has seb's mp
[14:43] <kenvandine> :/
[14:43] <robru> jgdx: http://people.canonical.com/~platform/citrain_dashboard/#?q=jgdx is authoritative
[14:43] <jgdx> robru, I don't know what that means
[14:43] <slangasek> sil2100, cyphermox: fyi I just verified that 'dpkg -c /path/to/the.deb' shows hardlinks with a 'foo link to bar'
[14:43] <kenvandine> jgdx, and the package in the ppa hasn't been rebuilt since the 13th
[14:44] <cyphermox> slangasek: thanks
[14:44] <cyphermox> turns out I already have a script that does most of the job to pick the packages
[14:45] <robru> jgdx: https://ci-train.ubuntu.com/job/ubuntu-landing-006-0-reconfigure/ does not show any signs of having been run. I suspect you opened the jenkins job page but then did not actually run the job.
[14:45] <jgdx> robru, I usually press build until it builds
[14:46] <jgdx> kenvandine, so this is why you append and not replace mps
[14:46] <robru> jgdx: a common problem is that you're not logged in so the first time you click build it redirects through the sso login without actually triggering the build. my guess is you clicked build once and then didn't click it a second time to make it actually go.
[14:46] <jgdx> robru, that I am aware of
[14:47] <robru> jgdx: anyway, the reconfigure job hasn't been run since March 16, and the dashboard shows the old mp, so I'm not sure what happened but the reconfigure definitely did not happen.
[14:47] <jgdx> robru, agh
[14:47] <jgdx> robru, I did not follow up properly on the reconfigure and build, obiously.
[14:48] <jgdx> robru, landing the tests later is fine by me.
[14:48] <jgdx> whatever we need to not waste om26er's time.
[14:49] <robru> jgdx: ok, sorry for the terribleness of this system, I am working on a replacement that will fix some of these issues but it won't be ready for a while yet
[14:49] <kenvandine> jgdx, so are you approving that MP?
[14:49] <jgdx> robru, this is my bad from the start
[14:49] <robru> jgdx: yeah if your branch *only* adds tests and doesn't actually change any behaviors, then you don't even really need a silo for that, can just push to trunk after the silo lands
[14:49] <om26er> jgdx, ;)
[14:50] <jgdx> robru, ack
[14:51] <jgdx> kenvandine, done
[14:51] <kenvandine> thx
[14:51] <kenvandine> robru, i guess you can push the button again :)
[14:51] <robru> jgdx: ok, I see your approval, will publish. thanks
[14:55] <om26er> Mirv, HI!
[15:02] <Mirv> om26er: hi
[15:02] <om26er> Mirv, re: silo4 does it really require us to run all manual tests of all apps ?
[15:03] <Mirv> om26er: I don't think so in this case, since it's a one line change. tsdgeos can possibly comment on the risk of that one line, but it was accepted in upstream stable branch.
[15:03] <Mirv> om26er: I already ran all AP:s + some of the manual tests myself
[15:03] <tsdgeos> are we talking about the regexp change?
[15:03] <Mirv> tsdgeos: yes
[15:04] <tsdgeos> it's very low risk
[15:04] <tsdgeos> veeeeeeeeeeeeery low
[15:05] <om26er> tsdgeos, It seems to be crashing still
[15:05] <tsdgeos> om26er: what is crashing still?
[15:06] <om26er> tsdgeos, I am running the test code in the bug report and it give: http://paste.ubuntu.com/10833552/
[15:06] <om26er> with and without the silo.
[15:07] <tsdgeos> well
[15:07] <tsdgeos> that is not crashing
[15:07] <tsdgeos> that's aborting
[15:07] <tsdgeos> the example is for running on the desktop
[15:07] <tsdgeos> not on the phone
[15:07] <tsdgeos> if you want to run it on the phone
[15:08] <om26er> oh
[15:08] <tsdgeos> you pass the -desktop_file_hint stuff as usual
[15:08] <tsdgeos> to make it understand it's "an approved app"
[15:08] <om26er> tsdgeos, right.
[15:17] <abeato> cyphermox, rsalveti I've seen an issue with NM silo, if I set then unset flight mode cellular connection is not always restored
[15:17] <abeato> probably was happening before, but...
[15:25] <rsalveti> abeato: not restored you mean not connecting to the network anymore?
[15:25] <rsalveti> or you mean the data connection?
[15:25] <rsalveti> surely not related with the silo, as it's a one line fix for wifi aps
[15:25] <abeato> rsalveti, the data connection is not activated by NM again
[15:25] <abeato> sure, I have the syslog so I will create a new bug to track this
[15:26] <abeato> I can easily reproduce
[15:26] <rsalveti> alright, interesting
[15:33] <rsalveti> abeato: let me know about the bug number once you create it
[15:34] <abeato> rsalveti, yep, just about to finish the writing :)
[15:34] <rsalveti> updating my desktop now so I can also test it there
[15:34] <rsalveti> brb
[15:37] <abeato> cyphermox, rsalveti bug #1445080
[15:40] <cyphermox> sil2100: slangasek: so far so good; but not done downloading packages.
[15:40] <sil2100> cyphermox: excellent, good to hear that ;)
[15:40] <cyphermox> slangasek: what was your control?
[15:41] <cyphermox> sil2100: ok; confirmed there were none in the list for armhf + all packages.
[15:41] <cyphermox> I'd just like to use the same package as slangasek used to check dpkg-deb -c output, to confirm I see the same thing
[15:41] <rsalveti> abeato: it seems I'm getting that with the current nm version as well
[15:41] <rsalveti> tested with mako and arale, and it didn't get the connection back after coming back from flight mode
[15:42] <abeato> rsalveti, ok good to know it is reproducible
[15:42] <abeato> ...and that is not the change in the silo
[15:42] <cyphermox> abeato: rsalveti: this isn't something new in my silo though
[15:43] <rsalveti> yeah, it's not
[15:43] <sil2100> cyphermox: slangasek is now doing a presentation so it might take a while
[15:43] <rsalveti> sil2100: hey, what's up with the overlay ppa?
[15:43] <rsalveti> sil2100: do we have it around already?
[15:43] <sil2100> rsalveti: yes, we created it on Monday, but not using it yet as the archive wasn't frozen
[15:43] <sil2100> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay
[15:44] <rsalveti> sil2100: right, but did we try a landing already?
[15:44] <rsalveti> sil2100: changed spreadsheet and etc
[15:44] <rsalveti> because once the freeze is in place this has to work :-)
[15:44] <rsalveti> brb, rebooting
[15:44] <sil2100> rsalveti: we did experimental landings through the spreadsheet to another PPA already ;)
[15:45] <cyphermox> sil2100: ok. checking against my cache.
[15:45] <sil2100> rsalveti: and since this is a PPA as any other, it's all cool - there's a new column for that (yay..) and all works nicely
[15:49] <rvr> dbarth: Approving silo 17
[15:50] <rsalveti> sil2100: alright then :-)
[15:50] <rsalveti> guess we just need to announce that later today
[15:50] <sil2100> Yeah, not much change to the workflow thankfully, just one column more to set and if not LT will set that for landers at the beginning period
[15:52] <cyphermox> sil2100: confirmed, we're good.
[15:52] <sil2100> cyphermox: excellent, thanks!
[15:52] <sil2100> slangasek: ^
[15:53] <sil2100> Preparing the release then, just might take a few moments as I'm in an important meeting
[16:01] <sil2100> robru: ^ handling that
[16:01] <robru> sil2100: cool
[16:21] <cyphermox> rsalveti: abeato: think we're good to go? looks fine on my end on dekstop
[16:21] <rsalveti> cyphermox: still testing, should know more soon
[16:22] <abeato> cyphermox, besides the bug not directly related to this landing it looks fine in arale
[16:22] <cyphermox> great.
[16:22] <cyphermox> it's going to be hard to land later than today
[16:32] <rsalveti> cyphermox: tried with one access point, and it went away after 5 minutes only on arale
[16:32] <rsalveti> still available on desktop and mako after 15 minutes
[16:34] <cyphermox> were there scans since then?
[16:35] <rsalveti> cyphermox: didn't force a scan, no
[16:35] <cyphermox> I don't see how you guys have so much trouble with this, I can easily test and reproduce the correct behavior with androidAP, it goes out after about 5-6 minutes as it's expected
[16:35] <rsalveti> but I'd expect to have at least one scan during that period
[16:35] <cyphermox> rsalveti: not necessarily
[16:35] <rsalveti> as I said, it only worked fine with arale
[16:35] <cyphermox> the driver can ignore scan requests too :/
[16:35] <rsalveti> not working with mako
[16:35] <rsalveti> and also not on my desktop
[16:36] <cyphermox> abeato: did you get the same issues?
[16:36] <cyphermox> rsalveti: are you sure you upgraded and restart NM properly?
[16:36] <rsalveti> cyphermox: yup
[16:36] <rsalveti> even rebooted my desktop
[16:36] <abeato> I've jus tried arale
[16:37] <cyphermox> rsalveti: so, how are you testing this exactly?
[16:37] <rsalveti> cyphermox: I have another physical router that I just plug and unplug from power
[16:37] <rsalveti> and watch nm to see if it disappears
[16:38] <cyphermox> so, nmcli g logging level debug domains wifi_scan and try again
[16:38] <cyphermox> then after about 10 minutes, if it still hasn't disappeared, send me your syslog
[16:41] <rsalveti> sure, trying again
[16:44] <rsalveti> takes a while to even show up after powering up my ap
[16:45] <rsalveti> 3 minutes and still nothing
[17:05] <rsalveti> cyphermox: on arale I see a new scan request at every 2 minutes
[17:07] <rsalveti> and the aps took around 6/7 minutes to be removed from the list
[17:08] <rsalveti> cyphermox: now on both my mako and desktop, I don't see a single scan request
[17:08] <rsalveti> explaining why it's never expiring the aps
[17:09] <rsalveti> as soon as I force a scan with 'iwlist wlan0 scan' the ap goes away
[17:09] <rsalveti> cyphermox: so 2 questions, why only scanning at every 2 minutes (arale), and any idea why I'm not getting any scans on mako and on my desktop?
[17:11] <cyphermox> don't know
[17:11] <cyphermox> but the scanning every 2 minutes is what NM is supposed to do when connected
[17:11] <cyphermox> background scanning too often would break some drivers
[17:11] <rsalveti> hm, right
[17:11] <cyphermox> (at least, in the past it did)
[17:12] <cyphermox> so, force a scan
[17:12] <cyphermox> not starting a scan is a different bug that would already be there
[17:13] <cyphermox> (and we'll fix it too, but yeah...)
[17:13] <rsalveti> the aps goes away after forcing scan
[17:13] <rsalveti> so that fix seems fine
[17:13] <cyphermox> I would imagine :D
[17:13] <cyphermox> so, ok to hand to QA?
[17:13] <rsalveti> cyphermox: mako seems it's only scanning when not connected
[17:13] <cyphermox> rsalveti: must be driver magic then :(
[17:13] <rsalveti> guess it would be the same on desktop
[17:13] <cyphermox> no
[17:13] <cyphermox> well
[17:13] <rsalveti> let me open a bug anyway
[17:14] <rsalveti> cyphermox: sure, hand it over
[17:14] <cyphermox> it depends on your driver really
[17:14] <rsalveti> abeato: all good from your side?
[17:14] <cyphermox> here it does scan while connected
[17:14] <abeato> rsalveti, yes
[17:14] <rsalveti> let me disconnect and see :-)
[17:15] <cyphermox> rsalveti: abeato: either of you can get me an image number you tested on?
[17:15] <abeato> cyphermox, arale vivid #12
[17:15] <cyphermox> thanks
[17:15] <rsalveti> cyphermox: 173
[17:15] <rsalveti> mako
[17:15] <rsalveti> vivid-proposed
[17:15] <cyphermox> ah
[17:19] <rsalveti> on my desktop it never scans unless I ask it to do so
[17:19] <rsalveti> connected/disconnected, doesn't matter
[17:19] <rsalveti> and mako is scanning just fine now after I disconnected and connected again
[17:19] <rsalveti> let me reboot to see if it's an issue when booting the device
[17:27] <rsalveti> cyphermox: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1445134
[18:06] <kenvandine> sil2100, adt tests has settings held up in proposed, boottest failure
[18:07] <kenvandine> sil2100, who should i bug about that?
[18:07] <sil2100> Ouch, kenvandine did you poke the CI team?
[18:07] <sil2100> Try cihelp ^
[18:07] <kenvandine> cihelp for blocked in proposed?
[18:07] <kenvandine> cihelp: please help, system-settings is blocked in proposed, boot test regression bug 1421009
[18:08] <kenvandine> but i doubt that had anything to do with unity8 hanging
[18:08] <sil2100> Yeah, well, they know best how these tools work, since boottests is their infrastructure
[18:08] <kenvandine> sil2100, ok, thx
[18:08] <kenvandine> i'll wait for cihelp :)
[18:09] <sil2100> Most CI is eating lunch now ;)
[18:09] <kenvandine> i should do that too :)
[18:09] <kenvandine> just anxious to be able to start a build for silo 24
[18:10] <Laney> kenvandine: I pressed the retry button ;-)
[18:10] <Laney> watch out for smoke on the horizon
[18:11] <kenvandine> Laney, thanks!
[18:12] <plars> kenvandine: which job was it? The referenced unity8 bug still causes boottest to be unreliable
[18:12] <plars> kenvandine: so until it's fixed, the only thing to do is retry afaik
[18:12] <kenvandine> plars, that's what i figured
[18:12] <kenvandine> just didn't want to let it sit long before getting it run again
[18:13] <kenvandine> oh, i might have permission to retry the test :)
[18:13] <Laney> you should do
[18:13] <kenvandine> i thought it was a archive admin thing :)
[18:14] <kenvandine> but just rebuilding the jenkins job i guess fixes it :)
[18:14] <Laney> ya
[18:14] <kenvandine> good to know!
[18:33] <pedronis> trainguards: you can free silo 16,  it's failing to build (because of a test) but anyway we discovered the fix is not needed because vivid doesn't have the problem to start with
[18:40] <sil2100_> pedronis: on it
[18:42] <pedronis> sil2100: thx
[18:42] <sil2100> pedronis: thanks for the info :)
[18:47] <rvr> cyphermox: Is silo 29 desktop only?
[18:47] <cyphermox> rvr: no, both
[18:48] <rvr> cyphermox: Be aware that we only check on phones.
[18:48] <cyphermox> that's fine
[18:48] <cyphermox> I've already checked on desktop
[18:49] <rvr> cyphermox: Ok. So, what can be checked in the phone, the wireless APs ranges?
[18:49] <Mirv> rvr: do you need anything for 002? just wondering if it'll make it before final freeze or to the ppa
[18:50] <rvr> Mirv: I'm trying to flash my Arale, didn't have the VPN setup.
[18:50] <cyphermox> rvr: no, you need to check whether an access-point discovered gets removed after about 5-6 minutes after no longer being in range
[18:50] <rvr> cyphermox: Yeah
[18:50] <cyphermox> rvr: easiest way to do that is to enable, say, a wifi hotspot in android, wait for it to be discovered, and then take it down
[18:51] <cyphermox> logs aren't extremely helpful for this; so you might want to enable debug logging: nmcli g logging level debug domains wifi_scan
[18:52] <cyphermox> (with sudo in front)
[18:52] <rvr> cyphermox: Ack. I'll leave that info iin the card, for the tester.
[18:52] <Mirv> rvr: ok.
[18:56] <robru> jgdx: ok, so now u-s-s landed, just take your MP with the tests and try to get that included in kenvandine 's silo ;-)
[19:47] <slangasek> cyphermox: dpkg-deb -c control was python3.4-minimal fwiw
[20:06] <kenvandine> bfiller,  can you add the milestone for the bugs i asked about this morning? bug 1438633 and bug 1437026
[20:06] <kenvandine> bfiller, i just set the silo as tested, so qa will be verifying :)
[20:08] <cyphermox> slangasek: found that out afterwards, find /usr -type -f -printf "%n %p\n" | grep -v 1
[20:15] <slangasek> cyphermox: yah ;)
[23:03] <sil2100> o/