[02:07] -ubottu:#ubuntu-news- ::planet:: Ubuntu Blog: Kubeflow vs MLFlow: which one to choose? @ https://ubuntu.com//blog/kubeflow-vs-mlflow
[08:53] -ubottu:#ubuntu-news- ::portugal:: E252 a Tua Tecnologia, as Tuas Regras @ https://podcastubuntuportugal.org/e252/


[11:21] <Ohio_> Have an Xubuntu question about sessions if someone can assist
[11:28] <Ohio_> I have two options when I log in one for xfce seesion and one for xubuntu session, is there a way to remove the xfce session?
[11:28] <cfhowlett> nope.
[11:29] <cfhowlett> not if you want to continue with xubuntu.  xfce is the display manager, after all
[11:33] <Ohio_> I previously had the machine auto login so I thought there might be a way, thank you for your time
[11:34] <cfhowlett> it will default to the last selection.
[11:36] <Ohio_> I just can't seem to get back to the original way I installed Xubuntu, it saved my password but I still have to hit enter for it to boot, thought the extra session was the issue
[11:37] <cfhowlett> nope.  that would be in your automatically login settings.
[11:39] <Ohio_> Can you tell me what I may be doing wrong on the automatic login issue then
[11:39] <cfhowlett> looking now ...
[11:41] <Ohio_> Thank you, all I see is don't ask for password on login but it still requies you to hit enter
[11:41] <cfhowlett> really?  that's doesn't seem right.
[11:42] <cfhowlett> got it.  reverse this https://www.wikihow.com/Disable-Auto-Login-in-Xubuntu
[11:50] <Ohio_> Thank you, rebooting now to see if it works
[11:51] <cfhowlett> fingers crossed
[11:56] <Ohio_> That did the trick, thank you again
[11:56] <cfhowlett> it's all in the wrist, my friend.  now go forth, be fruitful and sin no more.
[11:57] <Ohio_> LOL
[11:57] <Ohio_> Enjoy your weekend


[15:00] <rbasak> o/
[15:00] <rbasak> Who's here?
[15:00] <BenC> o/
[15:03] <rbasak> While we're waiting for quorum, any opinions on my ubuntu-devel SRU uploader permission thread?
[15:03] <BenC> If infinity can’t chair, I’m going to have to pass on chair. I’m also in a work meeting, so stretched for focus.
[15:04] <rbasak> OK
[15:04] <rbasak> I can chair (if we ever get quorum)
[15:04] <rbasak> What happened to the action to find more suitable meeting times?
[15:05] <micahg> hrm, I think I lost the poll (it expired)
[15:05] <BenC> I was expecting a list of times we could vote on, but I’m open to moving times.
[15:05] <BenC> I think I remember voting on something.
[15:06] <rbasak> I think that was micahg's poll.
[15:06] <rbasak> What's the reason half the DMB seem to always be missing?
[15:06] <micahg> new DMB, new schedules
[15:06] <micahg> these times have basically been the same for 6+ years
[15:06] <BenC> I usually have conflicts with conference calls
[15:07] <micahg> I occasionally have conflicts with conference calls and other meetings
[15:08] <rbasak> cyphermox: are you here?
[15:11] <rbasak> While we're waiting for quorum, any opinions on my ubuntu-devel SRU uploader permission thread?
[15:14] <BenC> rbasak: What’s the Sibject on that thread?
[15:15] <BenC> *Subject
[15:17] <cyphermox> I'm here.
[15:17] <cyphermox> bdmurray sends his apologies
[15:19] <rbasak> BenC: "Unblocking SRU uploader permissions"
[15:19] <rbasak> BenC: dated 2 Feb.
[15:21] <BenC> Thanks, reading over it now.
[15:25] <rbasak> Oh, we do have four now.
[15:25] <rbasak> #startmeeting Developer Membership Board
[15:25] <meetingology> Meeting started Mon Feb 13 15:25:16 2017 UTC.  The chair is rbasak. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:25] <meetingology> Available commands: action commands idea info link nick
[15:25] <rbasak> #topic Review of previous action items
[15:25] <rbasak> rbasak to get mapreri's PPU additions done by the TB (done)
[15:25] <rbasak> rbasak to address GunnarHj's im-config xenial question on the ML (done)
[15:25] <rbasak> rbasak to start a discussion on the ML regarding the possibility of setting up a specialized team with access to upload packages to stable releases only (done)
[15:25] <rbasak> So all done.
[15:25] <mapreri> yeah, done \o/
[15:25] <rbasak> I see no applications on the agenda, so straight to:
[15:26] <rbasak> #topic Outstanding mailing list requests to assign
[15:26] <rbasak> Are there any?
[15:26] <rbasak> "Please add xfdashboard to xubuntu packageset"
[15:26] <cyphermox> I can do that
[15:26] <jbicha> I believe fossfreedom's application has been waiting for votes for a while
[15:27] <cyphermox> I suppose I'll need to do another refresh of the packageset for Kubuntu today
[15:27] <rbasak> Thanks!
[15:27] <rbasak> #action cyphermox to handle Sean Davis' xfdashboard packageset request
[15:27] <meetingology> ACTION: cyphermox to handle Sean Davis' xfdashboard packageset request
[15:28] <rbasak> #action cyphermox to refresh Kubuntu packageset
[15:28] <meetingology> ACTION: cyphermox to refresh Kubuntu packageset
[15:29] <rbasak> Looks like micahg, cyphermox, sil2000 and I have already voted on fossfreedom's request.
[15:29] <micahg> yeah, that was addressed in a meeting
[15:30] <rbasak> Oh, and BenC voted too.
[15:31] <rbasak> jbicha: so fossfreedom needs a +1 from one or both of infinity or bdmurray, and neither are here.
[15:31] <rbasak> jbicha: everyone else has voted I think.
[15:31] <cyphermox> yeah, I don't remember that there was a mail about that -- the outcome was roughly that we needed to start defining a packageset before people applied to join it
[15:32] <rbasak> Well, I prefer to do it the other way round - agree in principle to a yet-to-be-defined packageset, then agree the packageset.
[15:32] <rbasak> But yeah, the packageset does eventually need to be defined.
[15:32] <cyphermox> well, we can't approve joining something that doesn't exist
[15:33] <micahg> it needs to be defined, not created before people can apply, we can defer creation until someone actually applies successfully
[15:33] <cyphermox> so, I would say, having a list of the few budgie-specific packages first would be a good thing
[15:33] <cyphermox> semantics
[15:33] <rbasak> I really don't think this matters.
[15:33] <rbasak> Anyway, this can't proceed without a +1 vote from bdmurray or infinity.
[15:34] <cyphermox> the LP tasks aren't a big deal, but I'm not going to approve a packageset being "whatever X puts in list Y" just like that, until I know that X is a core-dev, at least
[15:34] <rbasak> It would be the DMB.
[15:34] <cyphermox> or that the packages are very clearly within the purview of the list
[15:34] <cyphermox> so how we've always defined packagesets was:
[15:34] <cyphermox> figure out a phrase that generalizes what goes in it
[15:35] <cyphermox> then check package against definition, if it fits, add to packageset
[15:35] <rbasak> I still don't think this matters.
[15:35] <cyphermox> why?
[15:35] <rbasak> It's a bootstrapping problem. Unless fossfreedom gets a +1, even in principle, what the packageset might contain is moot.
[15:36] <rbasak> And you've already voted.
[15:36] <cyphermox> I'm already +1 for letting him upload some budgie-specific packages
[15:36] <rbasak> Right. And he doesn't have enough +1s.
[15:36] <rbasak> (AFAICT)
[15:36] <cyphermox> that's a different problem
[15:36] <rbasak> So let's get bdmurray and infinity to vote.
[15:37] <rbasak> Until then, is there anything further to discuss on this?
[15:37] <cyphermox> I'm certainly not +1 for letting him upload network-manager, for example. are you?
[15:37] <rbasak> No.
[15:37] <rbasak> But the DMB will not put network-manager into any future budgie packageset. I certainly wouldn't vote for that.
[15:37] <cyphermox> well then, are you +1 for budgie-welcome or whatever that package is?
[15:37] <rbasak> Sure.
[15:38] <rbasak> I mean for the packageset.
[15:38] <cyphermox> not for fossfreedom uploading?
[15:38] <rbasak> Not for fossfreedom I'm afraid, as I voted -1 for him to join any budgie packageset for reasons I've given.
[15:38] <cyphermox> I don't recall the reasons
[15:38] <rbasak> https://ubottu.com/meetingology/logs/ubuntu-meeting/2016/ubuntu-meeting.2016-12-12-19.03.log.html
[15:40] <rbasak> Is there anything further to discuss on this topic right now?
[15:40] <rbasak> If not let's move on.
[15:40] <cyphermox> no
[15:41] <rbasak> I don't see anything else outstanding on the ML. Dave Chiluk's vote appears to be progressing.
[15:41] <rbasak> #topic Any other business
[15:41] <rbasak> I'd like feedback on my ML thread about SRU uploaders please.
[15:42] <rbasak> Nobody on the DMB has replied.
[15:43] <rbasak> Based on the other replies so far, I'm in favour of having a new class of uploader - SRU uploaders, who can upload anything to the queues in stable releases. It seems that LP will support this. They'll still get a review from ~ubuntu-sru of course.
[15:43] <rbasak> But I have no idea what anyone else on the DMB thinks.
[15:43] <rbasak> Please tell me.
[15:48] <chiluk> I think our team would appreciate the intermediary positition for sure.
[15:48] <chiluk> And thanks to those who've already voted.
[15:50] <chiluk> rbasak.  I don't see a vote from you.  We could finish the vote now assuming you are a +1 on that.
[15:50] <chiluk> it'd be nice to put that to rest.
[15:51] <rbasak> I'll need to review, but I don't remember being confident about voting +1 for core dev. That's why I'd like to resolve the SRU uploader question.
[15:51] <chiluk> I realize you are probably wanting to grant sru-uploader .
[15:51] <rbasak> Right
[15:51] <sil2100> Sorry for being late, I always seem to think the meeting is an hour later...
[15:51] <chiluk> that's fine. I won't hold it against you.
[15:51] <rbasak> I'd also like to know what other DMB members think about what a core dev should mean.
[15:51] <micahg> sil2100: in another few weeks it will be ;)
[15:55] <rbasak> Anyone? Or are you all reading/thinking?
[15:56] <micahg> rbasak: I think I'm in the same boat as you
[15:56] <rbasak> OK, thanks.
[15:56] <rbasak> cyphermox? sil2100? BenC? Opinions?
[15:57] <micahg> (waiting to see outcome of SRU uploader discussion)
[15:57] <rbasak> Oh
[15:57] <rbasak> Well...what do you think about the SRU uploader discussion? :)
[15:58] <cyphermox> rbasak: I think it's fine, but it "adds" work to the SRU team (more careful review, but then again, you always need to be carefully reviewing the packages). You're in that team though, so you already know about it
[15:58] <micahg> I'm a bit conflicted, it's a novel idea for sure, I'm struggling with if it'll really solve an issue and if it's a direction we want to drive upload rights
[15:58] <cyphermox> (that means I'm +1)
[15:59]  * sil2100 needs to get some context, one moment
[15:59] <micahg> and I was worried about extra burden on SRU team as cyphermox mentioned
[15:59] <rbasak> cyphermox: thanks. Yeah, I'm always carefully reviewing anyway, and I think we should only give this to people we trust can do SRUs correctly (and well).
[16:00] <rbasak> I don't think we need uploaders to understand things like development release proposed migration and merges.
[16:01] <rbasak> cyphermox: so I don't think there's really anything we have to worry about with respect to the quality of uploads that the SRU team will see. Any concern about that for an individual and I'd be -1 to give that person SRU uploader permissions.
[16:01] <cyphermox> well, they need to understand proposed migration to a degree anyway
[16:02] <rbasak> I'm only looking to remove requirements that clearly don't apply to SRUs, but do to core devs, to get people uploading SRUs sooner.
[16:03] <rbasak> If, in your judgement of the requirements that are left, a candidate doesn't meet them, then I'd encourage you to vote -1 for SRU uploader anyway.
[16:03] <cyphermox> yeah yeah
[16:15] <sil2100> I'm +0 on the SRU-uploaders team
[16:16] <sil2100> Since even though I think in some cases it might be useful, I'm not sure that it's worth the trouble of getting it done, since I don't know if we'd have a lot of people applying for such a team membership
[16:16] <sil2100> Although I must say I d o not know how much work is required to get it implemented
[16:16] <slashd> sil2100, there will at least ~10 ppl from my team that would be willing to apply for this
[16:16] <chiluk> sil2100: we have about 20 on my team that would be interested
[16:17] <slashd> yeah
[16:17] <slashd> 20 sorry
[16:17] <tinoco> =)
[16:17] <rbasak> If it works, I believe it is just a matter of an LP team and an ACL entry by the TB.
[16:17] <rbasak> No more work than a new packageset.
[16:17] <tinoco> all of them following discussion
[16:17] <chiluk> slashd: cloudy folks need to do sru's as well.
[16:17] <slashd> chiluk, yep
[16:18] <sil2100> hm, ok, so there is need for that then, but you must remember that getting upload rights for that team will be similar to what we give to core-devs, so anyway possibly those people could have applied for core-dev as well
[16:18] <rbasak> BenC?
[16:18] <chiluk> sil2100: which is exactly what I did.
[16:19] <tinoco> sil2100: we wouldn't be touching devel
[16:19] <tinoco> rbasak: right ?
[16:19] <rbasak> tinoco: right. You'd still need a sponsor for devel.
[16:19] <chiluk> tinoco in most cases.
[16:19] <BenC> I would be +1 in theory, but I’m +/-0 at this point.
[16:19] <tinoco> which raises question .. we would start SRU (upload) without sponsor for devel ?
[16:19] <rbasak> Which is often a prerequisite for an SRU. However, I hope that it'll help speed things up (one sponsor needed once, rather than multiple times as stuff gets developed)
[16:19] <micahg> another unanswered question is whether or not we grant membership to this team, I would suggest not to keep the bar for entry lower.  However, it seems the SRU team might be flooded with requests.  Has that team grown sufficiently to handle such an influx of uploads?
[16:20] <sil2100> Yeah, just stable, but stable has even a bigger emphasis on good uploads, so uploaders need to have the knowledge - yes, there's the additional step of ubuntu-sru doing reviews of the uploads before accepting, but still
[16:20] <BenC> I’m personally more geared toward an SRU role for the STS team and we would vote on who, from that team could fill that role to unblock the team.
[16:20] <chiluk> micahg: it would be no more than current.
[16:20] <rbasak> Also I think it'll provide a nice stepping stone.
[16:20] <BenC> They would promote their best candidate
[16:21] <rbasak> micahg: I'm not sure the SRU numbers would go up. STS will still drive the same number of (Canonical) customer requests. My intention is to reduce the latency.
[16:21] <rbasak> micahg: but if the SRU numbers did go up, then I'd expect Canonical to put more into ~ubuntu-sru. Right now the majority of ~ubuntu-sru work is handled by Canonical staff anyway.
[16:21] <chiluk> correct rbasak... numbers should stay about the same.  Maybe slightly higher by allowing us more time to work instead of harass uploaders
[16:22] <rbasak> micahg: I recently joined ~ubuntu-sru to alleviate the load, as has sil2100 - and we're both sponsored by Canonical to do this.
[16:22] <chiluk> rbasak..becoming a member of ubuntu-sru has been one of my stated goals all along.
[16:22] <sil2100> Anyway, I'm fine with any outcome
[16:24] <rbasak> Thank you everyone for your opinions.
[16:24] <rbasak> I'll propose to add an ~ubuntu-sru-uploaders team then. I'll respond to the mailing list.
[16:25] <rbasak> And we can discuss it there, and vote for it either on the list or at the next meeting.
[16:25] <rbasak> I think we'd need a quorate vote.
[16:25] <rbasak> Any other AOB?
[16:31] <rbasak> OK, thanks all!
[16:31] <rbasak> #endmeeting
[16:31] <meetingology> Meeting ended Mon Feb 13 16:31:32 2017 UTC.
[16:31] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2017/ubuntu-meeting.2017-02-13-15.25.moin.txt
[16:31] <tyhicks> hello
[16:31] <tyhicks> #startmeeting
[16:31] <meetingology> Meeting started Mon Feb 13 16:31:57 2017 UTC.  The chair is tyhicks. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:31] <meetingology> Available commands: action commands idea info link nick
[16:32] <slashd> thanks rbasak for leading the discussion about the sru-upload, we appreciated it
[16:32] <tyhicks> The meeting agenda can be found at:
[16:32] <tyhicks> [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting
[16:32] <tyhicks> [TOPIC] Announcements
[16:32] <tyhicks> James Page (jamespage) provided a debdiff for xenial for nova-lxd (LP: #1656847)
[16:32] <tyhicks> Jeremy Bicha (jbicha) provided debdiffs for yakkety for bubblewrap and flatpak (LP: #1657357)
[16:32] <tyhicks> Jeremy Bicha (jbicha) worked to remove jasper from zesty (LP: #1612835)
[16:32] <tyhicks> Thank you for your assistance in keeping Ubuntu users secure! :)
[16:32] <tyhicks> [TOPIC] Weekly stand-up report
[16:32] <tyhicks> jdstrand: you're up
[16:33] <jdstrand> hi!
[16:33] <jdstrand> last week my dev work got preempted by lots and lots of reviews (store, documentation, Personal and other snapd PRs, snap-confine PRs) and helping with the snap-confine system vs core snap out-of-syncness issue on classic
[16:33] <jdstrand> today, I'm catching up on store reviews, various mailing list and bug discussions from friday/weekend
[16:33] <jdstrand> this week, I plan to continue with various PR and design reviews/discussions as I'm assigned to them. I know I already need to look at the gsettings patches, console access, 'notion of trust' in snappy, misc snap-confine PRs and lots of Personal PRs (unity8 policy, thumbnailer, media-hub, et al)
[16:33] <jdstrand> assuming I can get to my non-review assigned dev work after, I plan to work on the next batch of miscellaneous policy updates and continue with more seccomp arg filtering policy
[16:34] <jdstrand> (quite a bit of the seccomp arg filtering policy I pushed up landed already)
[16:34] <jdstrand> that's it from me
[16:34] <jdstrand> mdeslaur: you're up
[16:35] <mdeslaur> I'm on triage this week
[16:35] <mdeslaur> I was about to publish a webkit2gtk update, but the new version has a regression
[16:35] <mdeslaur> I'm still working on php5 updates, should be publishing that this week
[16:35] <mdeslaur> after that, I'll be going down the list, as usual
[16:35] <mdeslaur> sbeattie: you're up
[16:39] <tyhicks> I'll go and we can circle back
[16:39] <tyhicks> I'm in the happy place this week
[16:39] <tyhicks> finish testing and submit seccomp logging kernel patchset v3
[16:39] <tyhicks> check on AppArmor Zesty upload (blocked by a perl upload)
[16:39] <tyhicks> assist in landing the dconf/gsettings mediation
[16:40] <tyhicks> tcpdump updates (bug #1662177)
[16:40] <tyhicks> that's it for me
[16:40] <tyhicks> jjohansen: you're up
[16:40] <tyhicks> oh, short week for me
[16:40] <tyhicks> I'm out tomorrow
[16:41] <jjohansen> I'm finishing up the apparmor policy notification interface, and making any other revisions to the dconf work that might pop up
[16:41] <jjohansen> once that is done I'll be back to upstreaming work, the next merge window is coming all too fast
[16:42] <jjohansen> oh hrmm and it goes with out saying that revising the dconf/gsettings work is part of landing it
[16:42] <jjohansen> which I'll be helping with
[16:43] <tyhicks> I think that'll be a full week
[16:43] <jjohansen> yep
[16:43] <tyhicks> I haven't seen sarnold yet
[16:43] <tyhicks> he's working on MIRs
[16:43] <tyhicks> chrisccoulson: you're up
[16:43] <jjohansen> yeah, I was just checking
[16:43] <sarnold> (here)
[16:43] <tyhicks> oh, go ahead
[16:44] <sarnold> I'm community this week
[16:44] <chrisccoulson> This week, I'll be spending some more time getting rustc working everywhere
[16:44] <sarnold> whatever's not spent on community tasks will be MIRs :)
[16:44] <chrisccoulson> Mozilla just bumped the minimum rustc version required to build firefox to 1.15.1, which is newer than we have in zesty, which is totally awesome
[16:44] <chrisccoulson> oh
[16:44] <sarnold> ow
[16:44] <tyhicks> :(
[16:44] <chrisccoulson> sarnold, carry on :)
[16:45] <sarnold> I'm done :/
[16:45] <chrisccoulson> ah, cool
[16:45] <sarnold> because waiting a dozen hours for a toolchain before starting work on the browser sounds like such fun :(
[16:45] <chrisccoulson> so, other than that, I'll be finishing off bug 1638852, and then a few other cleanups required to make the new UITK webview stable
[16:45] <chrisccoulson> That's me done
[16:45] <ratliff> I'm on bug triage this week.
[16:46] <ratliff> I am working on updates for core and touch otherwise
[16:46] <ratliff> sbeattie: around? if not, back to you tyhicks
[16:47] <tyhicks> lets move on
[16:47] <tyhicks> [TOPIC] Highlighted packages
[16:47] <tyhicks> The Ubuntu Security team will highlight some community-supported packages that might be good candidates for updating and or triaging. If you would like to help Ubuntu and not sure where to start, this is a great way to do so.
[16:47] <tyhicks> See https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures for details and if you have any questions, feel free to ask in #ubuntu-security. To find out other ways of helping out, please see https://wiki.ubuntu.com/SecurityTeam/GettingInvolved.
[16:47] <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/pinpoint.html
[16:47] <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/gcc-4.9.html
[16:47] <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/libcsoap.html
[16:47] <tyhicks> [TOPIC] Miscellaneous and Questions
[16:47] <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/gpw.html
[16:47] <tyhicks> Does anyone have any other questions or items to discuss?
[16:47] <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/libxml-security-java.html
[16:49] <tyhicks> jdstrand, mdeslaur, sbeattie, jjohansen, sarnold, ChrisCoulson, ratliff: Thanks!
[16:49] <tyhicks> #endmeeting
[16:49] <meetingology> Meeting ended Mon Feb 13 16:49:39 2017 UTC.
[16:49] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2017/ubuntu-meeting.2017-02-13-16.31.moin.txt
[16:49] <jjohansen> thanks tyhicks
[16:49] <ratliff> thank you, tyhicks !!
[16:49] <mdeslaur> thanks tyhicks!
[16:50] <sarnold> thanks tyhicks!
[16:50] <jdstrand> thanks tyhicks :)


[05:41] <silvarion> Hello, just testing if this channel works before going to bed
[05:41] <silvarion> Tomorrow I'll be back to chat a little bit about porting ubuntu-touch to the Sony Xperia Z
[05:42] <silvarion> Blessings for everyone!
[07:00] <zzarr> hello! will ota-13 be built on another version of Ubuntu? (other then 15.04)
[07:13] <yakaar> Bonjour à tous, j'ai un gros soucis, un ami a fais malencontreusement tombé mon portable aquaris E4.5, l'écran est brisé, mais le téléphone est encore allumé, mais en  veille. Le tactile n'est plus fonctionnel, que faire ??
[07:20] <zzarr> yakaar, English please
[07:25] <yakaar> Sorry, I forgot, my mobile has its screen broken and no function is working, I want to change my screen how to find another??
[07:30] <duflu> yakaar: First ask the point of sale if it's covered under warranty. Usually the answer is no, but ask there first. Second go to any regular phone shop/repairer and they should be able to get a replacement screen for you eventually. I can see they can be sourced unofficially on eBay etc.
[07:42] <zzarr> duflu, do you know the answer to my question?
[07:43] <duflu> zzarr: Good question. I don't know
[07:43] <duflu> zzarr: Our plan is to move phones to 16.04 as a base. But that might take longer
[07:43] <zzarr> okey
[07:44] <duflu> I believe the 'stable' channel is still vivid (15.04) as a core, but overlayed with the latest Ubuntu Touch
[07:45] <zzarr> what qt version?
[07:46] <zzarr> I wonder, if I wanted to use Qt 5.7 (or 5.8 when it comes), would be possible to use in a snap package
[07:53] <kaisoz> hi
[07:56] <kvmmm> So I'm reading, Ubuntu for Ubuntu-phone is the exact same OS as full Ubuntu, just with some GUI configurations to make it work nicely on a phone?
[07:56] <kvmmm> So I can run any Ubuntu software on the phone?
[07:59] <zzarr> kvmmm, it's experimental yet but yes
[08:00] <kvmmm> ok, cool. So what about something like... KVM and Whonix?
[08:02] <zzarr> it's called libertine, it uses XMir
[08:03] <sil2100> Ubuntu touch has some differences from regular Ubuntu, but the base system is built from the same parts
[08:05] <zzarr> I have tried Firefox and GIMP on my phone and it works
[10:56] <Mirv> zzarr: stable is Qt 5.4, staging channels are Qt 5.6 (well, soon anyway). 5.6 is the upstream LTS version so the next stable will be based on that.
[10:56] <Mirv> (staging = 16.04)
[10:57] <Mirv> 16.04 will be needed for the snap support (15.04 has the older click format), but I'm uncertain what kind of snaps can be used. certainly it would be possible to bundle newer Qt in a snap, but the system would use what's testsed to be stable, that is Qt 5.6
[11:03] <zzarr> thanks Mirv
[11:04] <zzarr> Mirv, if I successfully built an application in Qt 5.5.1, would I be able to run it on my phone?
[11:04] <zzarr> (OTA-12)
[11:08] <Mirv> zzarr: maybe, most applications use the Qt public ABI that is at least forward compatible, often also backwards compatible
[11:08] <Mirv> there weren't too many new functions in 5.5
[11:09] <zzarr> I know
[11:09] <zzarr> okey
[11:09] <zzarr> thanks
[11:11] <zzarr> I installed the 5.5.1 overlay in an schroot
[11:15] <zzarr> how ever the kit remains on 5.4, how can I "tell it" to use 5.5.1?
[11:31] <REAPer61616> Hi!
[11:32] <REAPer61616> Can someone tell me if is there ubuntu touch based on android 6.0.1?
[11:33] <REAPer61616> means availible source
[12:11] <robinhero> hi guys! Please +1 these bug reports if you are also affected:
[12:11] <robinhero> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1573193
[12:11] <robinhero> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1609719
[13:17] <kaisoz> hi mimecar
[13:17] <mimecar> good evening kaisoz
[13:59] <jgdx> mterry, hey, any progress on the uss datetime issue?
[14:00] <mterry> jgdx: no, as I said, it's on the bottom of my priority list right now -- doing MIRs to get u8 stack into yakkety right now
[14:00] <jgdx> mterry, ack
[14:23] <Mirv> hmm, if I have an obsolete "ubtd.mzanetti_shareplugin_0.3" in my Share dialog, where would I remove traces of it? it's no longer installed, as it got upgraded to 0.4 which shows in the dialog too with a better name and an icon
[14:24] <Mirv> I tried grepping .[a-z]* but didn't find anything useful sounding to clean
[14:24] <tedg> mariogrip: hey, mhall119 mentioned that you might have a nexdock as well. What device are you connecting to it?
[14:26] <Mirv> oh, the fix is called "reboot"
[14:30] <mariogrip> tedg: Yes, we will support any Ubuntu touch and Android devices, we are also looking into Ios but it seems like its too locked down for us
[14:30] <tedg> mariogrip: Sure, I was curious which Ubuntu touch devices you were using.
[14:31] <mariogrip> tedg: sorry, that was to another person, (copy paste fail)
[14:31] <tedg> mariogrip: The N4 works, but it's.... old hardware...
[14:31] <mariogrip> tedg, nexus 5 :)
[14:32] <mariogrip> maybe an miracast dongle, so i can try Oneplus one and Fairphone 2
[14:33] <tedg> mariogrip: Ah, interesting, I don't know using miracast would be great.
[14:33] <tedg> mariogrip: Didn't know that the N5 had external display
[14:34] <mariogrip> yeah, but the nexus 5 has slimport so that should work just fine
[14:34] <tedg> mariogrip: Do you know if the OPO 3 has slimport?
[14:34] <tedg> That's what I *really* want to work :-)
[14:34] <mariogrip> and that i fixed bluetooth it should be perfect
[14:34] <mariogrip> opo 3, nope
[14:34]  * tedg drools over 6GB of RAM
[14:35] <mariogrip> buuut, i got something in mind so we can use the usb port to transfer hdmi
[14:35] <tedg> I thought there was some standard there for USB-C, no?
[14:36] <mariogrip> yes it is usb-c but it's still usb 2.0
[14:36] <mariogrip> so, it's just the port that is different
[14:38] <tedg> Ah, yeah.
[14:40] <dobey> yeah it's kind of messed up that made it 2.0 on usb-c
[14:40] <dobey> that is totally not standard
[17:36] <taiebot> awe: I have a network related question. Hope it will be clear enough. I just want to make sure that UT has nothing to do with this.  I am currently changing phone provider and i am in the process of transferring my phone number. I have given my PAC code to my new provider (Three) and I am currently having issues with this. I can call with my number on three (Correctly transferred) but all the call received are still tra
[17:42] <awe> taiebot, your last message was cut off
[17:42] <awe> what phone are you using?
[17:42] <taiebot> awe: Nexus 4
[17:43] <awe> and do you have another phone you could try, to ensure it's not UT?
[17:43] <awe> so you can make outgoing calls, but what's happening with incoming?
[17:43] <awe> that's the part that was cutoff
[17:43] <taiebot> awe: they all get cut off.
[17:44] <taiebot> awe: repasting the end of the message
[17:44] <taiebot> awe: . I had a quick chat with a representative of three which explained to me that there could be some problems with some config files and they would try to fix it within 24h. In case they do not manage to solve this and its due to the phone what do you recommend me to do?  Would you like a debug of some sorts? Hopefully it is at their end. Thank you for your answer.
[17:45] <taiebot> awe: it is certainly at their end
[17:45] <awe> what do you mean "cut off"?
[17:45] <awe> you call from another phone, and it never starts ringing?
[17:46] <awe> and doesn't go to VM either?
[17:46] <taiebot> but all the call received are still transferred to my old provider (not correctly transferred ) and therefore are dropped because i am using the sim from three on my phone.
[17:46] <awe> yea, that sounds like nothing to do with UT
[17:46] <awe> again, do you have another phone you can test the SIM in to confirm?
[17:47] <awe> if you can confirm it works in another phone, then it's time to file a bug, collect logs, ...
[17:47] <awe> but right now, I don't hear enough evidence from you to warrant starting all that
[17:48] <awe> it really sounds like # porting didn't fully take effect
[17:48] <taiebot> awe: cool thank you, yes i can try on another phone. My concern if it's a sim configuration it could get right into the other phone and when i put it back to UT it 's all ok
[17:54] <awe> taiebot, the only thing UT touches on a SIM is a file used for message-waiting indication.  If the SIM is from three, it should just work
[17:59] <taiebot> awe: Ok just wanted to make sure i am not sure this has been done very often on an ubuntu touch and just wanted to make sure i did not had a weird bug
[18:08] <dobey> taiebot: it worked fine for me when i had to get a new SIM from my provider. was same provider, but still had to assign a diff number and then port the number over, but when i first enabled an ubuntu phone i had to do that
[18:14] <taiebot> dobey: Ok thanks makes me less worried
[18:15] <cariveri> hi. since last update the ubuntu-phones apps like Telegram dont notify anymore. is this known? can I do anything about it?
[18:16] <dobey> cariveri: are you logged in to U1 in System Settings -> Accounts?
[18:21] <cariveri> dobey: yes.
[18:26] <dobey> cariveri: if you go to updates panel does it ask you to log in again?
[18:27] <cariveri> no
[18:30] <dobey> hmm, ok. don't know why you wouldn't be getting push notifications then. maybe check logs in ~/.cache/ to see if something's going on. not sure exactly where ubuntu-push-client logs are in there, but should be in there somewhere
[19:55] <gihel> anyone has the same problem with sms notifications ? it doesn't ring after a while, the phone vibrate but I don't get any sound
[19:56] <gihel> I thought it was related to radio apps that interfered with something, but even withour using radio apps this bug occurs
[19:56] <gihel> without*
[19:57] <gihel> after rebooting the phone, it's ok for a  while
[20:03] <dobey> gihel: i'd suggest filing a bug about that
[20:45] <TheKit> does anyone know if Android should still run with libhybris's bionic TLS slot shift patch applied?
[21:13] <gihel> ok dobey, will do some more tests and I will file a bug this week end, thank you


[09:58] <dholbach> good morning everybody and welcome to another MOTU Q&A session!
[09:59] <dholbach> I think we'll start again with a round of introductions
[09:59] <dholbach> I'm Daniel Holbach, been MOTU for quite a long time already, am trying to make becoming a MOTU easier and to make Ubuntu Universe rock even harder
[10:00] <norsetto> I'm Cesare Tirabassi, fresh MOTU
[10:01] <dholbach> ... and great contributor :-)
[10:01] <lool> I'm Loc Minier, would like to become MOTU
[10:01] <norsetto> and living proof that anybody can become a MOTU :-)
[10:01] <dholbach> norsetto: hahaha :)
[10:01] <dholbach> lool: great to have you around
[10:01] <dholbach> who else do we have?
[10:02] <slangasek> I'm Steve Langasek, MOTU wannabe
[10:02] <dholbach> heya slangasek, hey \sh
[10:02] <dholbach> anybody else? :)
[10:03] <dholbach> ok... seems we have only people around who are quite familiar with packaging already
[10:03] <dholbach> do you have any questions yourself?
[10:03] <dholbach> maybe about processes or how the MOTU team deals with things?
[10:04] <lool> Yes; I'd like to know how build failures on buildd should be handled and why I receive such notices
[10:04] <lool> For example I received two build failures for synaptic; it seems one arch was set to Needs-Build again (hppa IIRC)
[10:05] <dholbach> good question
[10:06] <dholbach> Soyuz (the buildd part of Launchpad) sometimes sends out build error mails when build-deps can not be properly installed, in a lot of cases this is not your fault at all
[10:06] <dholbach> that's something the Soyuz folks should fix, it's a bit annoying to have to check the buildlog before just deleting the error mail
[10:06] <lool> Am I supposed to do something with the notice?
[10:07] <slangasek> roll it up and hit lamont over the head with it ;)
[10:07] <dholbach> If you figured out that it's not your fault, no :)
[10:07] <lool> Hehe
[10:07] <lool> I wonder whether other bug reporters get similar spam and why?
[10:07] <norsetto> lool: we all get ......
[10:07] <lool> (I didn't prepare the synaptic upload, I only reported a bug)
[10:08] <dholbach> lool: oh?
[10:08] <lool> Ah wait I did
[10:08] <dholbach> lool: maybe that's part of the ChangelogClosesUbuntuBug thing?
[10:08] <lool> mvo didn't replace my name when he added his changes
[10:08] <dholbach> oh good *phew* :-)
[10:08] <dholbach> right
[10:08] <lool> Ok, I'm relieved as well
[10:09] <dholbach> in any case it's a good idea to talk to the folks on #launchpad if anything like that creeps up and is not explicable
[10:10] <dholbach> any other questions?
[10:10] <dholbach> do we have somebody here who's new to packaging and would like to benefit from the packaging experience we have gathered in #ubuntu-classroom right now? :)
[10:10] <dholbach> a package review? build problem? something?
[10:11] <lool> I have another question about attaching debdiffs to bug reports; is it ok to use "UNRELEASED" in the target dist or should I use gutsy?
[10:12] <dholbach> lool: I personally would use 'gutsy' and also (LP: #123456)
[10:12] <dholbach> that way it's just a matter of applying it, trying and uploading it
[10:12] <dholbach> I personally find UNRELEASED only useful for VCS commits
[10:12] <dholbach> lool: is that common for sponsored uploads in Debian?
[10:12] <lool> What do you mean by "and also (LP: #123456)"?  You mean instead of "; LP: #123456." which I used?
[10:13] <dholbach> oh, no - that's not what I referred to
[10:13] <dholbach> "LP: #123456." should be fine too
[10:13] <slangasek> dholbach: not IME; I agree with you that UNRELEASED is only useful when you're sharing around something in an intermediate state
[10:13] <lool> dholbach: It's just that I saw a sponsor requesting an updated debdiff with s/UNRELEASED/gutsy and wondered whether this was a strict requirement
[10:13] <dholbach> I just meant that if you make use of ChangelogClosesUbuntuBug and specify the upload target it's less work for the sponsor
[10:13] <lool> Ok; naurally I close bugs in changelogs
[10:14] <dholbach> lool: it's not strict afaik
[10:14] <norsetto> I would say its good practice though
[10:14] <dholbach> that's great - it's mainly new contributors who forget to use it, but you all know how to use it :-)
[10:15] <dholbach> hey adam_b - how are you doing?
[10:15] <dholbach> adam_b: here for the MOTU Q&A session?
[10:15] <lool> Ok; I have a question about bug states when reporting: I think I now have the bug triaging capability, but I'm new to it and I'm sometimes in doubt with bug states: should I set a bug to "confirmed" after I report it?
[10:15] <adam_b> dholbach: I'm doing ok, yep thought I might listen in
[10:15] <norsetto> lool: no, we should never confirm our own bugs
[10:15] <lool> (In order to avoid bug triage)
[10:15] <dholbach> adam_b: rock on
[10:16] <dholbach> adam_b: if you have any questions regarding packaging, becoming a MOTU or something else - just ask :)
[10:16] <dholbach> lool: in some cases it's OK to do that - I think pitti's requestsync script for example sets to 'confirmed' automatically
[10:17] <dholbach> but the archive admins will recognize your name on the bug report anyway and probably know that you know what you're doing
[10:18] <dholbach> any other questions?
[10:18] <lool> Hmm bash tells me requestsync is in devscripts, but I have devscripts and no requestsync script
[10:18] <dholbach> lool: thanks for that - I'll tell mvo to update command-not-found-data
[10:18] <dholbach> lool: it moved to ubuntu-dev-tools
[10:19] <lool> Ok, thanks
[10:19] <adam_b> dholbach: there's a package from debian 'mapnik' that is half in ubuntu, just wondered why that might be? there is .gz's but no .debs
[10:19] <dholbach> adam_b: ok, let's take a look at http://launchpad.net/ubuntu/+source/mapnik together
[10:20] <dholbach> it seems the source for mapnik 0.4.0-2 arrived in Ubuntu alright
[10:20] <adam_b> cool
[10:20] <dholbach> if you look at https://launchpad.net/ubuntu/gutsy/+source/mapnik/0.4.0-2
[10:20] <dholbach> you will find that it failed to build on all architectures
[10:20] <dholbach> let's take a look at the build logs
[10:21] <adam_b> failed to build
[10:21] <dholbach> python scons/scons.py PROJ_INCLUDES=/usr/include PGSQL_INCLUDES=/usr/include/postgresql PROJ_LIBS=/usr/lib DESTDIR=/build/buildd/mapnik-0.4.0/debian/tmp PREFIX=/usr BIDI=yes PYTHON=/usr/bin/python2.5 --clean
[10:21] <dholbach> scons: Reading SConscript files ...
[10:21] <dholbach> Checking for main() in C library m... no
[10:21] <dholbach> Could not find header or shared library for m, exiting!
[10:21] <dholbach> make: *** [clean]  Error 1
[10:21] <dholbach> a scons build issue, it seems
[10:21] <adam_b> its cpp app and build thinks its c?
[10:22] <adam_b> oh no next line
[10:23] <dholbach> it has problems in Debian as well, it seems
[10:23] <slangasek> why do you say that? it's up-to-date on all archs in Debian
[10:24] <lool> dholbach_: Missed some lines?
[10:24] <adam_b> when I build it in a gutsy chroot I have to build with sudo python scons/scons GDAL_INCLUDES=/usr/include/ install
[10:25] <dholbach_> adam_b: you shouldn't have to use sudo - try fakeroot
[10:25] <adam_b> ok
[10:25] <adam_b> even for the install part?
[10:26] <slangasek> only for the install part
[10:26] <dholbach> slangasek: I saw this http://bjorn.haxx.se/debian/testing.pl?package=mapnik
[10:26] <slangasek> for the non-install part, you should deliberately avoid using fakeroot or sudo, to make sure the package builds cleanly as a normal user
[10:27] <slangasek> dholbach: well, "waiting for boost" isn't a bug in mapnik
[10:27] <lool> Here it cleans fine; perhaps it's a missing build-dep
[10:27] <slangasek> (hmm, I immediately want to retract that comment after saying it, clearly depending on boost /is/ a bug ;)
[10:31] <adam_b> so in ububut build its looking for 'm' which is math.h (in SConstruct)
[10:33] <dholbach> I'm afraid I can't offer an answer to this one
[10:34] <adam_b> fakeroot gives: scons: *** [/usr/local/lib/libmapnik.so]  /usr/local/lib/libmapnik.so: Permission denied
[10:35] <dholbach> upstream have received a similar report: http://trac.mapnik.org/ticket/14 - but it's not of much help
[10:35] <slangasek> adam_b: then you're missing the DESTDIR=$(CURDIR)/debian/tmp from the original
[10:38] <dholbach> I think it might make sense to raise awareness of this failing to build on<EMAIL_ADDRESS>[10:39] <dholbach> not sure we'll find an answer right here, right now
[10:39] <dholbach> do we have any other questions?
[10:40] <dholbach> adam_b: did you start to actively dive into MOTU things already?
[10:43] <adam_b> dholbach: nope, just contemplating writing an app that will use mapnik
[10:43] <dholbach> adam_b: ahh nice
[10:43] <dholbach> hey huats
[10:44] <huats> hey
[10:44] <huats> dholbach: what a surprise to see you here
[10:44] <dholbach> welcome huats, another soon-to-be-MOTU ;-)
[10:44] <huats> dholbach: ;-)
[10:44] <dholbach> huats: do you have any questions? anything we could take a look at together?
[10:44] <huats> dholbach: yes I have
[10:44] <dholbach> rock on
[10:44] <dholbach> :-)
[10:44] <huats> I am searching it :-)
[10:45] <dholbach> I knew we could count on huats :-)
[10:45] <huats> alwasy count on me where there are questions to ask
[10:45] <dholbach> hehe
[10:46] <huats> it is related to bug #137513
[10:46] <dholbach> http://launchpad.net/bugs/137513
[10:46] <huats> ubotu is down ?
[10:46] <ubotu> Sorry, I don't know anything about is down ? - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[10:46] <lool> (Just for the record: I don't get the failure on mapnik in pbuilder)
[10:47] <norsetto> bug 137513
[10:47] <huats> the last comment from pkern bothers me a bit...
[10:47] <dholbach> lool: me neither
[10:47] <huats> hey norsetto
[10:47] <norsetto> huats: hola, I have some info you you (later)
[10:47] <dholbach> lool: we had weird scons problems in sbuild (at least I think so) before
[10:47] <huats> norsetto: ?
[10:48] <dholbach> huats: it's best to ask asac about that
[10:48] <norsetto> huats: sorry, for you
[10:48] <huats> norsetto: ok
[10:48] <huats> dholbach: ok
[10:48] <dholbach> huats: I don't know about a policy decision on iceweasel in package names
[10:49] <huats> it is the only one apparently...
[10:49] <dholbach> right
[10:49] <dholbach> in debian there are lots of iceweasel-* binary packages
[10:49] <dholbach> in ubuntu it would be just this one
[10:49] <dholbach> so best to check with asac and ask if it should be renamed to mozilla-torbutton or firefox-torbutton
[10:50] <huats> dholbach: ok
[10:50] <huats> dholbach: I will
[10:50] <dholbach> super thanks
[10:51] <dholbach> anything else? anything more we can review? :)
[10:51] <huats> I have a second question to fire : can you explain me a bit the process to transmit bug fixes to debian... I know norsetto tried to many times, but I am sure it is someting interesting for many of us
[10:52] <dholbach> soren wrote submittodebian (in ubuntu-dev-tools) maybe that'd help with it?
[10:52] <huats> oh
[10:52] <huats> great
[10:52] <huats> I'll have a look
[10:53] <norsetto> dholbach: I think huats has some problems about what should be sent to Debian, in particular re. debdiff
[10:53] <huats> norsetto reads my mind
[10:53] <dholbach> right... I think the diff the debian maintainer could apply to the current source in sid would be most useful
[10:54] <dholbach> but we have two experienced Debian folks here, ... :-)
[10:54] <norsetto> three ....
[10:56] <dholbach> slangasek, lool: huats just asked " can you explain me a bit the process to transmit bug fixes to debian... I know norsetto tried to many times, but I am sure it is someting interesting for many of us" - do you have an answer for that?
[10:57] <huats> dholbach: if you want we can have a look to a precise bug entry to see what is sendable to debian...
[10:57] <dholbach> submittodebian is particularly useful for merges it seems
[10:57] <lool> The best case would be to confirm the bug is still present in Debian by actually running a Debian and checking the bug and patch, then using reportbug to report the bug with the patch; that's probably a long process for simple bugs though
[10:57] <dholbach> submittodebian has the advantage that you can edit the diff
[10:57] <dholbach> and remove stuff that is ubuntu specific
[10:57] <lool> So I guess one simpler case is simply checking whether the packages were patched in Debian or not
[10:58] <huats> ok
[10:58] <slangasek> dholbach: I was refraining from comment because my views on how Ubuntu should send bugfixes back to Debian seem to be at odds with the prevailing opinion within Ubuntu :)
[10:58] <slangasek> but as a Debian maintainer, if someone in Ubuntu has made a change that they think fixes a bug, I would like to hear about it directly through the Debian BTS
[10:58] <dholbach> slangasek: right, but given the question from somebody who wants to submit a patch to the debian bts? :)
[11:00] <slangasek> btw, the actual submittodebian script seems to be missing from current ubuntu-dev-tools, only the manpage is there
[11:00] <dholbach> oh?
[11:00] <huats> dholbach: so I'll use the debian BTS ...
[11:00] <dholbach> slangasek: I'll fix that in a sec - there's another change to it pending
[11:01] <dholbach> (need to talk to Sren about that)
[11:02] <dholbach> ok, asked him
[11:02] <dholbach> if there are no more questions, this is the end of this MOTU Q&A session
[11:02] <dholbach> we'll have one next week - I'll just ask for a proposal of a different time before :-)
[11:03] <dholbach> thanks everybody for your questions and answers
[11:03] <dholbach> have a nice day
[11:03] <huats> dholbach: thanks to you
[11:03] <lool> Thanks!
[11:04] <slangasek> cheers


[09:18] -queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/4206 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[09:18] -queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/4207 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[10:06] -queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/4206 Ready to build
[10:07] -queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/4207 Ready to build
[12:44] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4203 Needs rebuild due to higher version at destination
[12:52] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4191 Needs rebuild due to burned version number
[17:00] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3840 Needs rebuild due to higher version at destination (focal/systemd). Ready to build (focal/rust-getopts, focal/vim)
[21:42] -queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/4208 Preparing packages
[22:29] -queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/4206 Generating diffs
[22:30] -queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/4206 Ready to build


[01:26] <davecheney> here's a quick review, https://github.com/juju/juju/pull/5410
[01:40] <anastasiamac> davecheney: reviewed
[01:43] <davecheney> ta
[01:57] <mup> Bug #1582463 opened: juju subordinate not allocating and can't be destroyed <canonical-bootstack> <juju-core:Triaged> <juju-core 2.0:New> <https://launchpad.net/bugs/1582463>
[02:38] <davecheney> it takes 16 minutes to run the state tests on my machine
[02:45] <natefinch> davecheney: I have a branch where I'm adding if testing.Short(){ c.Skip() } to all the longest tests until each package takes no more than 1 seconds to test.  That should drop the time to run a smoke test dramatically.  Not that it'll help when you really want to run the full suite.
[02:45] <natefinch> davecheney: it also does that to all mgosuites and jujuconn suites in the suitesetup, skipping the entire suite, because, seriously, no.
[02:46] <natefinch> brb
[02:46] <davecheney> natefinch: i only care about the tests taht CI runs
[02:53] <mwhudson> davecheney: are you testing against mongo 3.2 now?
[02:54] <mwhudson> hm, doubt it
[02:54] <davecheney> mwhudson: nope
[02:56] <davecheney> mwhudson: what i mean is
[02:57] <davecheney> my setup has not changed since 14.04
[02:57] <davecheney> so whatever was happening before i went on leave when the state tests did pass
[02:57] <davecheney> is no longer happening
[02:58] <mwhudson> davecheney: oh right, of course
[02:58] <mwhudson> was just a stray thought anyway
[02:58] <davecheney> mwhudson: fwiw, CI doesn't run mongo 3.2
[02:58] <davecheney> so, there's that
[02:58] <mwhudson> davecheney: yeah, i expect some tests still fail
[02:59] <davecheney> could someone who's a mod on the juju-dev mailing list please approve my message that is slightly larger than the 40kb message limit
[03:17] <natefinch> davecheney: but what about all those poor souls on their 2800 baud modems?
[03:18] <anastasiamac_> natefinch: some ppl believe that terrible experiences enrich souls :-P
[03:20] <natefinch> anastasiamac_: I think some people just can't get out of the 1999 mindset
[03:20] <anastasiamac_> natefinch: 1999? when was that? :-P
[03:22] <davecheney> wepl, ya'll miss out on my satorial wit
[04:21] <mup> Bug #1556442 changed: juju quickstart looks for network-bridge: "lxcbr0" in local environment <bootstrap> <quickstart> <juju-core:Expired> <https://launchpad.net/bugs/1556442>
[04:21] <mup> Bug #1557874 changed: juju behaviour in multi-hypervisor ec2 clouds <juju-core:Expired> <https://launchpad.net/bugs/1557874>
[06:03] <davecheney> here is a simple one https://github.com/juju/juju/pull/5413
[06:25] <mup> Bug #1581748 opened: [2.0b7] add-credential no longer supports maas as a cloud type <cdo-qa> <credentials> <maas> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1581748>
[06:25] <thumper> o/
[06:25] <thumper> davecheney: you should have an amusing email to read now
[06:26] <davecheney> thumper: :)
[06:26] <davecheney> are you a mod on juju-dev ?
[06:26] <davecheney> can you approve my less than amused email ?
[06:26] <thumper> yep
[06:26] <thumper> um... not the ubuntu juju-dev list, no
[06:26] <thumper> I think that is still just gustavo
[06:31] <elmo> thumper: no, it's Becky^WWilliam
[06:31] <thumper> elmo: oh, thanks
[06:35] <elmo> the mailing list moderation is a cluster - I'm going to arbitrarily drop all the held messages; some of them date back to 2013
[06:35] <elmo> the majority are spam; and I can't believe the non-spam ones are still relevant
[06:35] <thumper> heh
[06:45] <dimitern> thumper: heh, it seems I dodged it but frobware got on that plane after all?
[06:45] <thumper> dimitern: he will be
[06:46] <dimitern> thumper: ah, not yet I see
[06:47] <dimitern> sometimes not having a visa might be good for a change
[06:55] <mup> Bug #1582555 opened: deploy cs:trusty/ubuntu deploys Xenial charm <juju-core:New> <https://launchpad.net/bugs/1582555>
[07:42] <dimitern> rogpeppe: ping
[07:42] <rogpeppe> dimitern: pong
[07:44] <dimitern> rogpeppe: hey, I'm seeing a consistent test failure in cmd/jujud/agent/machine_test.go:TestDyingModelCleanup - http://paste.ubuntu.com/16472327/
[07:45] <rogpeppe> dimitern: and it might be because of my recent change?
[07:45] <dimitern> rogpeppe: I did a git bisect and surprisingly it turned out your PR #5404, commit https://github.com/juju/juju/commit/2a731745eb2bb75f5ed20a887f23d9f198c16259 is the first time it happens
[07:45] <rogpeppe> dimitern: interesting
[07:46] <dimitern> rogpeppe: surprisingly, because it doesn't seem your PR touched anything near cmd/jujud/agent
[07:46] <rogpeppe> dimitern: i don't think i believe that
[07:46] <rogpeppe> dimitern: i don't think gce is even linked in to those tests
[07:47] <dimitern> rogpeppe: well the only thing that comes to mind is ProviderSchema added in environs/interface.go, but not implemented by the dummy provider?
[07:47] <rogpeppe> dimitern: it's just an interface declaration
[07:47] <rogpeppe> dimitern: nothing uses it
[07:47] <dimitern> rogpeppe: yeah, that's why it's a mystery..
[07:48] <dimitern> rogpeppe: can you try running cmd/jujud/agent$ go test -check.v -check.f MachineSuite.TestDyingModelCleanedUp on master tip and see if it passes?
[07:49] <dimitern> might be related to different go versions..  I can't see any way to get CollectionInfo in the mgo docs.
[10:54] <babbageclunk> dimitern: seems like I'll just have to check the error text - yay! And then guess the right size when I recreate.
[10:55] <dimitern> babbageclunk: it seems Collection.Create only returns CollectionInfo
[10:56] <babbageclunk> dimitern: I don't want to have to try to intercept the create calls so I can stash the infos somewhere.
[11:20] <lazyPower> my new favorite thing:  juju debug-log --replay -T > bacon.log
[11:21] <lazyPower> you guys/gals are killin it. <3
[11:21] <lazyPower> and if this was always there, i just found it and it feels like my birthday all over again
[11:22] <dimitern> lol lazyPower
[11:23] <lazyPower> o/ dimitern
[11:27] <dimitern> lazyPower: o/ it's always good to hear a happy user with all the issues we dealt with for 2.0 :)
[11:28] <lazyPower> its been a schlog, happy to spread the cheer when I can :D
[11:30] <lazyPower> I have some questions for you specific to spaces and how we can leverage them in k8s. I'd like to replace flannel with network-spaces in our kubernetes-core bundle. But we're a couple weeks out in terms of planning. I'll poke you in #juju when we're ready - prepare yourself ;)
[11:31] <dimitern> lazyPower: k8s ?
[11:31] <dimitern> aah :)
[11:32] <dimitern> lazyPower: well spaces are well supported mostly on maas, with some support on aws
[11:32] <lazyPower> ah right, its similar to storage in the fact its hamstrung by provider support
[11:32] <lazyPower> good point
[11:37] <lazyPower> welp thats something to think on
[11:38] <dimitern> lazyPower: yeah, we plan to add support for spaces to public clouds first, but it will take some time
[11:39] <mup> Bug #1582667 opened: i/o timeout when deploying/upgrading charm <juju-core:New> <https://launchpad.net/bugs/1582667>
[12:12] <lazyPower> dimitern completely understood. no pressure :)
[12:12] <lazyPower> i mean, networking is easy right?
[12:12] <lazyPower> said no-one ever
[12:15] <dimitern> lazyPower: :D indeed
[13:42] <mup> Bug #1582714 opened: worker/resumer: test failure during CI <juju-core:New> <https://launchpad.net/bugs/1582714>
[13:51] <mup> Bug #1582731 opened: github.com/juju/juju/state tests time out on centos <blocker> <centos> <ci> <regression> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1582731>
[14:00] <mup> Bug #1582731 changed: github.com/juju/juju/state tests time out on centos <blocker> <centos> <ci> <regression> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1582731>
[14:12] <mup> Bug #1582731 opened: github.com/juju/juju/state tests time out on centos and windows <centos> <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1582731>
[14:27] <katco> natefinch: hey just wanted to say thank you for getting that bug addressed
[14:27] <katco> natefinch: i'm sure ian is breathing a sigh of relief :)
[14:28] <natefinch> katco: welcome, yeah, I was glad to be able to fix it in a timely manner
[14:49] <natefinch> katco: trivial review of the deps change for that? http://reviews.vapour.ws/r/4852/
[14:49] <katco> natefinch: tal
[14:49] <katco> natefinch: ship it
[15:01]  * perrito666 has sandpaper in his throat
[15:02] <natefinch> perrito666: you should try eating food instead
[15:02] <perrito666> natefinch: nah, I am too hardcore for that
[15:02] <perrito666> I think Ill be making sign language for the next standup
[15:22] <mup> Bug #1582714 changed: worker/resumer: test failure during CI <juju-core:New> <https://launchpad.net/bugs/1582714>
[15:54] <natefinch> grep -r '"admin"' --include="*.go" . | wc -l
[15:54] <natefinch> 231
[15:54] <natefinch> screw dry, I wish we could at least manage something less than soaking wet
[15:54] <natefinch> damp?  moist?
[15:55] <katco> natefinch: now is your chance :) stick it somewhere sane
[15:55] <natefinch> katco: yep
[15:55] <thumper> histerical raisons
[15:55] <thumper> there is a testing.AdminUser
[15:56] <natefinch> oh, that's the best part.  Half of these are usernames, not model names
[15:56] <natefinch> possibly more than half
[15:56] <perrito666> natefinch: same happened with file urls
[15:56] <natefinch> I don't know because THEY'RE JUST STRINGS
[15:56] <perrito666> there was a bunch constructed by hand
[15:57] <bdx> hows it going everyone? I feel like I'm missing something here ... is there a way around this -> https://github.com/juju/juju/issues/5411 ?
[15:57] <natefinch> (╯°□°）╯︵ ┻━┻
[15:57]  * perrito666 touches natefinch with the "well fix it" wand
[15:58] <natefinch> thumper: package testing?
[15:58] <perrito666> bdx: hello, sorry I dont know
[15:58] <katco> bdx: we track our bugs on launchpad. here's a dupe with activity: https://bugs.launchpad.net/juju-core/+bug/1571593
[15:58] <perrito666> dimitern: voidspace any of you is familiar with that error?
[15:58] <mup> Bug #1571593: lxd bootstrap fails with unhelpful 'invalid config: no addresses match' <juju-release-support> <lxd-provider> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1571593>
[15:58] <thumper> github.com/juju/juju/testing
[15:58] <perrito666> katco: mm, we should go around closing the ones in gh every now and then
[15:59] <katco> perrito666: we try. we need to turn off GH issues completely, but there always seems to be something more important to work on... :(
[15:59] <perrito666> meh, I dont have supercow powers, I cant close the bug
[15:59] <perrito666> I added the link to the lp one in the comments
[16:00]  * katco closed the bug
[16:00] <bdx> Oh my bad, I should be filing those in lp huh
[16:00] <bdx> oops
[16:00] <bdx> thanks
[16:00] <katco> bdx: no worries, it's a common mistake. we don't make it clear at all
[16:00] <dimitern> perrito666: that's lxd related
[16:00] <perrito666> bdx: it is, I just saw the address part
[16:01] <perrito666> sorry to disturb you :)
[16:01] <dimitern> perrito666: it usually means lxdbr0 was misconfigured
[16:01] <bdx> perrito666: I'm doing everything I can to not use lxdbr0
[16:02] <bdx> but I guess I should of scouted out the bugs further
[16:02] <bdx> shoot
[16:02] <bdx> ha
[16:02] <bdx> sorry
[16:04] <bdx> dimitern, perrito666: is it a bug with lxd then?
[16:05] <perrito666> bdx: not really, there is a previous step to be done but apparently we are not documenting it?
[16:05] <perrito666> bdx: run lxd init
[16:05] <perrito666> and your problem should go away after networking setup
[16:06] <bdx> perrito666: yea, I've ran `lxd init` enough to no avail
[16:06] <perrito666> mmm, very strange
[16:08] <perrito666> try dpkg-reconfigure lxd and then restart lxd-bridge service
[16:08] <bdx> perrito666: I can bootstrap lxd just fine when using lxdbr0
[16:08] <perrito666> ah ok, then what do you do
[16:08] <perrito666> to make it fail?
[16:09] <bdx> perrito666: any host only bridge works for me ... its when I try to configure lxd to use a bridge on an external interface that it fails
[16:09] <perrito666> mm, my knowledge of lxd does not go that far sorry
[16:10] <perrito666> ericsnow: ^ do you know more about that?
[16:10] <bdx> should the issue be raised with lxd then?
[16:10] <ericsnow> perrito666: not really; perhaps tych0?
[16:10] <perrito666> ericsnow: he is not here :)
[16:11] <natefinch> thumper: sorry, my question was - why is a production value being defined in a testing package?
[16:11] <perrito666> bdx: ill try to summon someone from lxd, otherwise, file the bug with juju since we are the ones that break in that case
[16:13] <mup> Bug #1582798 opened: After bootstrapping, juju gui isn't automatically deployed <cpe-sa> <juju-core:New> <https://launchpad.net/bugs/1582798>
[16:13] <mup> Bug #1582799 opened: Deploying from the cli api.jujucharms.com is not reachable <cpe-sa> <juju-core:New> <https://launchpad.net/bugs/1582799>
[16:16] <babbageclunk> dimitern: I've got the state tests working for mongo3.2 now, except for TestSetAdminPassword.
[16:16] <babbageclunk> thumper: ^^
[16:16] <bdx> perrito666: the bug already exists .... its just not very specific to the nature of what actually happens -> https://bugs.launchpad.net/juju-core/+bug/1571593
[16:16] <mup> Bug #1571593: lxd bootstrap fails with unhelpful 'invalid config: no addresses match' <juju-release-support> <lxd-provider> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1571593>
[16:16] <bdx> I'll add in my bits to it
[16:16] <dimitern> babbageclunk: awesome!
[16:16] <dimitern> babbageclunk: is it as fast as 2.4 ?
[16:17] <perrito666> bdx: the error seems to be the same but they state a different cause
[16:17] <perrito666> could yolu please describe your case in that bug as a follow up?
[16:17] <babbageclunk> dimitern, thumper: but this change between 2 and 3 means that I think Initialize will have to work differently: https://docs.mongodb.com/manual/core/security-users/#localhost-exception
[16:18] <babbageclunk> dimitern: need to rerun the whole package again now that I've whacked all the moles - hang on.
[16:18] <babbageclunk> dimitern: but within a minute of 2.4 definitely.
[16:19] <babbageclunk> dimitern: which is better than 100x
[16:19] <bdx> perrito666: surely
[16:19] <perrito666> bdx: tx a lot
[16:20] <bdx> np
[16:20] <bdx> thank you
[16:24] <dimitern> babbageclunk: great news then! \o/
[16:24] <babbageclunk> dimitern: But so my final problem: at the moment Initialize connects to localhost without auth and creates the collections and indexes from allCollections(), and then at some point in the future sets an admin password - is that right?
[16:25] <dimitern> babbageclunk: AIUI 'some point in the future' is at test(suite?) teardown/reset
[16:26] <babbageclunk> dimitern: No, I mean in a real bootstrapped controller.
[16:26] <babbageclunk> dimitern: almost all the tests run with auth turned off.
[16:26] <dimitern> babbageclunk: ah, so the process goes - bootstrap with generated pwd, then when the controller's jujud agent starts, it resets the admin pwd once
[16:28] <babbageclunk> ok - but in state.Initialize it does all of the collection and index creation before that, right? I think the admin password just needs to be done earlier.
[16:30] <babbageclunk> dimitern: oh, no - I've found it in agentbootstrap.InitializeState - it's setting the password first, isn't it. Ok, I just need to fix the test then. Sweet!
[16:43] <mup> Bug #1582801 opened: Juju debug-log returns error when using during bundle deployment <cpe-sa> <juju-core:New> <https://launchpad.net/bugs/1582801>
[17:25] <mup> Bug #1582818 opened: SSH Key in MAAS GUI not working <maas> <ssh> <juju-core:New> <https://launchpad.net/bugs/1582818>
[17:44] <elmo> davecheney: not sure what you mean; I approved your mail before flushing the queue
[17:58] <bdx> perrito666, dimitern: this would explain alot -> https://github.com/juju/juju/blob/master/tools/lxdclient/client.go#L232-233
[18:00] <perrito666> really? we are checking for eth0? that is quite easy to break
[18:02] <perrito666> bdx: this check might be wrong https://github.com/juju/juju/blob/master/tools/lxdclient/client.go#L241-248
[18:07] <natefinch> quick review anyone? http://reviews.vapour.ws/r/4854/
[18:08] <bdx> yea, yea, I saw the whole part after the comments .... cry cry
[18:12] <redir> fwereade: yt?
[18:13] <natefinch> perrito666, katco, ericsnow: super easy, I promise: http://reviews.vapour.ws/r/4854/
[18:14] <perrito666> natefinch: rviewing
[18:15] <perrito666> natefinch: what prompts this change?
[18:15] <ericsnow> natefinch: there, that wasn't so bad <wink>
[18:16] <natefinch> perrito666: Mark
[18:16] <perrito666> say no more
[18:17] <natefinch> ericsnow: yeah, turns out there actually was a constant, it just was hard to find amongst all the other "admin" references
[18:17] <perrito666> natefinch: reviewed
[18:23] <natefinch> perrito666: good catch on that comment https://pbs.twimg.com/media/B3qIJLFCcAEJLWm.jpg
[18:23] <perrito666> natefinch: I believe that I lack the etnicity to catch that joke :p
[18:23] <tych0> bdx: ericsnow: i think you have to use lxdbr0 right now
[18:24] <natefinch> perrito666: the label says rice, the container contains cookies
[18:24] <perrito666> pass it through the I am southamerican filter
[18:24] <tych0> there's no way to configure it otherwise
[18:24] <natefinch> perrito666: it's about comments being out of date
[18:24] <perrito666> natefinch: I assumed they where rice cookies (things that happen when you live with celiac people)
[18:26] <perrito666> by default I suspect of any sort of bakery product not made/bought by me to be rice based :p
[18:30] <natefinch> perrito666: fairly uncommon here
[18:31] <perrito666> here, too, unless here==my house
[18:35] <mup> Bug #1582841 opened: remove check for lxdbr0 <juju-core:New> <https://launchpad.net/bugs/1582841>
[18:44] <bdx> tych0, perrito666, dimitern: I named the bridge on my external interface lxdbr0 .. this tricked juju, and lxd, and got me bootstrapped :-)
[18:44] <perrito666> lol
[18:44] <bdx> so simple, so sweet
[18:53] <natefinch> just found our 15 month old in an awkward ball, face down in a chair, unresponsive.... turned out he'd just fallen asleep and kind of slumped into a pile.
[18:53] <natefinch> and unresponsive only because he was so tired
[19:01] <perrito666> natefinch: and how is your panic attack?
[19:07] <natefinch> perrito666: fine once it was established he was sleeping, but geez
[20:22] <redir> when do I want to return errors.Trace(error) vs. error ?
[20:22] <redir> is there a rule of thumb?
[20:22] <redir> katco: natefinch ericsnow ^^
[20:22] <katco> redir: .Trace just adds stack information to the underlying object
[20:22] <natefinch> redir: basically always trace
[20:22] <katco> redir: really not a reason to not use it
[20:23] <katco> redir: .Annotate et. al. will do it for you, so you don't need to wrap those in .Trace
[20:23] <redir> OK just modifying a func that does both and wasn't sure why.
[20:23] <mup> Bug #1582881 opened: destroying a subordinate returns an error but seems to work <juju-core:New> <https://launchpad.net/bugs/1582881>
[20:23] <natefinch> redir: probably started being written before we had the errors library
[20:23] <katco> redir: probably targeted fixes. .Trace is only ~2y old
[20:24] <redir> should I .Trace it in the drive by?
[20:24] <natefinch> redir: if it's not too many of them, that's fine.
[20:24] <katco> redir: yeah i'd say those are easy to review, so bring the function up to code (no pun intended)
[20:26]  * redir nods. just one of three...easy enough.
[20:27] <natefinch> gah, why is it get-model-config and not show-model-config? :/  everything else is show :/
[20:28] <tvansteenburgh> why doesn't `juju block` accept a -m arg?
[20:31] <tvansteenburgh> is it an oversight? am i right to assume that the block command does indeed apply to one specific model?
[20:31] <natefinch> tvansteenburgh: not sure
[20:33] <natefinch> tvansteenburgh: it definitely is per model according to the comments
[20:33] <tvansteenburgh> natefinch: okay, thanks
[20:34] <natefinch> tvansteenburgh: must be an oversight... I think because it's built as a super command (i.e. juju block destroy-model .. destroy model is a command, not an argument)
[20:37] <natefinch> tvansteenburgh: can you file a bug?
[20:37] <tvansteenburgh> natefinch: sure thing
[21:21] <ericsnow> anastasiamac_: ping
[21:41] <anastasiamac_> ericsnow: o/
[21:43] <anastasiamac_> ericsnow: m making coffee - 7.40am.. bbiab
[21:43] <ericsnow> anastasiamac_: np
[21:43] <ericsnow> anastasiamac_: just thinking we may want to postpone our meeting until the syslog stuff is more settled
[21:54] <katco> anastasiamac_: was going to suggest the same
[21:59] <anastasiamac_> katco: ericsnow: sounds good \o/
[21:59]  * redir doesn't know about meeting
[21:59] <anastasiamac_> i'll move the meetings
[22:00] <mup> Bug #1582892 changed: `juju block` doesn't accept -m arg <juju-core:Invalid> <https://launchpad.net/bugs/1582892>
[22:00] <anastasiamac_> ericsnow: katco: altho m not convinced that the user stories will actually change :D
[22:00] <anastasiamac_> redir: i'll fill u in during standup
[22:00] <ericsnow> anastasiamac_: yeah, probably not :)
[22:00] <anastasiamac_> redir: perrito666: m happy to have a standup earlier if it suits u
[22:01] <anastasiamac_> ericsnow: m still keen to talk to u if u want :D but will move the actual meeting booking
[22:01] <perrito666> anastasiamac_: works for me
[22:02] <anastasiamac_> redir: want to do standup now-ish?
[22:02] <redir> anastasiamac_: fine by me, running tests now so I have time
[22:02] <redir> :)
[22:03] <perrito666> I am in the room
[22:03] <mup> Bug #1582892 opened: `juju block` doesn't accept -m arg <juju-core:Invalid> <https://launchpad.net/bugs/1582892>
[22:03] <anastasiamac_> redir: perrito666: m going to tanzanite now then \o/
[22:06] <mup> Bug #1582799 changed: Deploying from the cli api.jujucharms.com is not reachable <cpe-sa> <juju-core:Invalid> <https://launchpad.net/bugs/1582799>
[22:06] <mup> Bug #1582892 changed: `juju block` doesn't accept -m arg <juju-core:Invalid> <https://launchpad.net/bugs/1582892>
[22:12] <mup> Bug #1582799 opened: Deploying from the cli api.jujucharms.com is not reachable <cpe-sa> <juju-core:Invalid> <https://launchpad.net/bugs/1582799>
[22:27] <mup> Bug #1582799 changed: Deploying from the cli api.jujucharms.com is not reachable <cpe-sa> <juju-core:Invalid> <https://launchpad.net/bugs/1582799>