[08:03] <xnox> usbmuxd packages synced.
[09:09] <michagogo> Hi, I don't see a link in the topic regarding policy or rules or guidelines for this channel, so I'm sorry if I shouldn't be repeating this again (last time was 14ish hours ago, I think):
[09:09] <michagogo>  What needs to happen for bug #1314616 to move forward? How does the process work and get advanced from here?
[09:19] <cjwatson> michagogo: It's already listed on http://reqorts.qa.ubuntu.com/reports/sponsoring/, so there's no need to continue asking - it's in the sponsorship queue
[09:19] <michagogo> cjwatson: ah, okay -- so it's just a matter of someone in the project getting around to looking at it?
[09:20] <michagogo> That's all I wanted to know. Thank you!
[09:21] <cjwatson> michagogo: Right
[09:21] <cjwatson> It's in the right place AFAICS
[09:23] <michagogo> cjwatson: awesome, thank you! I just wanted to make sure it wasn't stuck on some action or change or correction or something that Scott or I or someone needed to do
[09:23] <michagogo> (Or something along those lines)
[10:48] <mpt> Wellark, hi. When your device is set up as a Wi-Fi hotspot, how easy is it to tell how many devices are connected to it?
[11:51] <xnox> bdmurray: ev_: is there a definitive way to query whoopsie as to which parameters it's using to derive the unique identifier? E.g. is it using IMEI or MAC address or other serial id?
[11:52] <ev_> xnox: I don't have the command to hand, but if you point gdbus at the service it will tell you
[11:54] <rbasak> infinity: so juju-core FTBFS on sagari also, so it's still stuck in -proposed. May I have some help with this, please? As I can't reproduce on a porter, I'm pretty stuck.
[12:39] <mlankhorst> Laney: feel like trying http://paste.debian.net/104091/ ?
[12:40] <mlankhorst> you had a >= nvc0 right?
[13:03] <tseliot> bdmurray: hi, I have two packages associated with some SRUs. Can you help please? nvidia-prime (precise-proposed) [LP: #1326257, LP: #1296020], ubuntu-drivers-common (trusty-proposed) [LP: #1306928, LP: #1296020, LP: #1310023]
[13:10] <Laney> mlankhorst: I dunno what that means
[13:11] <mlankhorst> Laney: what does glxinfo say in OpenGL renderer string ?
[13:12] <Laney> mlankhorst: Gallium 0.4 on NVE4
[13:12] <mlankhorst> ok give that patch a try
[13:13] <Laney> okey pokey
[13:35] <Laney> mlankhorst: umm I can't actually start the webbrowser app at all now
[13:35] <Laney> dunno if that's your fault
[13:39] <mlankhorst> oh funstuff
[13:39] <mdeslaur> xnox: could you please comment on the apparmor upstart job in bug #1305108...I have added  few questions to it
[13:39] <mlankhorst> Laney: can you do a backtrace, see where it hangs? :P
[13:40] <xnox> mdeslaur: you mean systemd job?! =)

[13:40] <Laney> mlankhorst: sec
[13:40] <Laney> getting oxide debug symbols
[13:40] <Laney> huge dbg package is huge
[13:40] <mdeslaur> xnox: at some point yes, but we need this for the phone before rtm
[13:41] <mlankhorst> Laney: don't need that, just the -dbg symbols from the mesa package i think
[13:41] <Laney> it has oxide in the bt
[13:41] <mlankhorst> is the bt usable without oxide?
[13:42] <Laney> dunno, didn't look, just went to install them
[13:42] <Laney> give me a second, it's installing now
[13:45] <mlankhorst> ok
[13:48] <jdstrand> xnox, mdeslaur: fyi, I just added a few comments too
[13:53] <Laney> mlankhorst: http://paste.ubuntu.com/7618198/ hope that helps
[13:54] <mlankhorst> stuck on mtx_lock.. hm
[13:56] <mlankhorst> oops, missed a pipe_mutex_unlock
[14:00] <mlankhorst> Laney: http://paste.debian.net/104107/ ?
[14:00] <Laney> sec
[14:35] <Laney> mlankhorst: I don't see any difference
[14:35] <psusi> how do you tell bzr not to fscking unapply quilt patches for me?  it always seems to fsck things up and right now it isn't letting me pull/update because it can't unapply a patch
[14:36] <ScottK> bzr doesn't apply or unapply patches.
[14:37] <psusi> ScottK: it does it all the time
[14:38] <psusi>  bzr update
[14:38] <psusi> Unapplying quilt patches to prevent spurious conflicts
[14:38] <cjwatson> That's bzr-builddeb
[14:38] <psusi> ok, well whatever plugin is doing it, it's making bzr unapply patches
[14:39] <psusi> and it always seems to muck everything up when it does
[14:39] <cjwatson> There are various properties like quilt-smart-merge to control it
[14:39] <psusi> in this case, bzr pull --overwrite is leaving my tree out of date still... update fails beacuse unapplying some patch fails... I can't find a way to just make my tree exactly like the current remote
[14:40] <psusi> is there somewhere I could read up on that?
[14:41] <cjwatson> bzr revert; rm -rf .pc; and then http://people.canonical.com/~cjwatson/dpkg-quilt-setup usually does it
[14:41] <cjwatson> as a "no really"
[14:41] <psusi> tried revert, and deleting .pc
[14:42] <cjwatson> /usr/share/doc/bzr-builddeb/user_manual/configuration.html
[14:42] <psusi> ohh, then push -a eh?  didn't try that
[14:42] <cjwatson> that script unapplies everything manually and then pushes, to synchronise .pc with the tree state
[14:43] <psusi> for that matter, why is pull --overwrite leaving the tree out of date?
[14:44] <cjwatson> the bzr-builddeb docs don't mention 'quilt-smart-merge = False' which may also be useful
[14:44] <cjwatson> don't recall
[14:45] <mlankhorst> Laney: bleh, I probably missed another mutex_unlock then :/
[14:52] <mlankhorst> Laney: is there anything in dmesg?
[14:53] <Laney> mlankhorst: nope
[14:59] <mlankhorst> found another one I missed, grr
[15:23] <Laney> I thought you were able to reproduce this
[15:24] <mlankhorst> Laney: hm what are you trying? because normal case works for me :P
[15:24] <Laney> $ webbrowser-app
[15:24] <Laney> → app hangs
[15:25] <Laney> I never see its interface
[15:26] <mlankhorst> definitely works for me, weird
[15:27] <mlankhorst> oh wait you're on utopic right?
[15:28] <Laney> yep
[16:08] <infinity> rbasak: I can try to have a poke at it.  Go isn't my forte.
[16:15] <rbasak> infinity: thanks! I'm not really sure where to go without being able to reproduce
[16:15] <rbasak> I'd want identical hardware and kernel and rootfs to start I think.
[16:16] <cjwatson> maybe it's the page size thing?
[16:17] <cjwatson> oh, powerpc, not ppc64el, hmm
[16:17]  * cjwatson falls over himself stepping back again
[16:31] <infinity> rbasak: So, it reproduces on my machine running a trusty kernel.  That would imply it's not a precise kernel issue.
[16:32] <rbasak> infinity: can you see if it reproduces in a Trusty chroot? I wondered if had anything to do with toolchain changes in Utopic.
[16:34] <infinity> Though, curiously, reproduces in a different spot.
[16:34] <infinity> That's not comforting.
[16:40] <infinity> rbasak: So, ever attempt on utopic seems to crash in a different spot.  Fun.
[16:41] <infinity> rbasak: And on trusty, it worked, at least on the first try.
[16:43] <infinity> rbasak: Also, the debian/rules clean target of this package assumes all UNIX machines are single-user. :P
[16:43] <infinity> rm -rf pkg bin /tmp/go-build* debian/home
[16:43] <infinity> rm: cannot remove '/tmp/go-build368800735': Operation not permitted
[16:47] <rbasak> infinity: so we have some kind of gccgo regression here?
[16:47] <rbasak> I'll take a look at the /tmp/go-build* thing for next upload
[16:50] <infinity> rbasak: I'll do a few more trusty test builds to confirm it always works there, then I'm a bit stuck at to why it works in the dirty porter chroot and not my clean sbuild chroot.
[16:51] <infinity> rbasak: First step might be to try to install all the packages in the porter chroot locally, but I can't see why gccgo-go/gccgo would care about random external packages.
[16:53] <infinity> rbasak: And yeah, building in /tmp is a very silly thing.  Not sure if that's juju's fault or gccgo-go (inherited from golang).
[19:33]  * popey wonders who could look at bug 1326707 - the 14.10 live CDs have been broken for a while.
[19:39] <trifort> popey: I can look at it, but I will be slow
[19:39] <trifort> popey: I am new, but I could spend the rest of the day
[19:40] <popey> I don't know if it's something an expert in the field would need to look at to be honest.
[19:41] <trifort> popey: if no one else has time, I’ll spend a while to see what I come up with
[19:42] <popey> thanks.
[19:44] <trifort> popey: okay, I’ll see what I find
[20:27] <tedg> bdmurray, It seems that popey's touch images aren't uploading any crash files.
[20:27] <tedg> bdmurray, Is there something he should be doing? I thought it was on by default?
[20:29] <popey> is there a switch I can flip, or indeed look at
[20:31] <tedg> popey, It should be Settings → Security & Privacy → Diagnostics → App crashes and reports
[20:31] <bdmurray> popey: grep whoopsie /var/log/syslog and I'll bet there is a No StacktraceAddressSignature message in there
[20:34] <bdmurray> tedg: the issue is that most of the stacktraces on armhf are corrupt
[20:35] <tedg> bdmurray, Oh, that's a bit scary, is there a fix?
[20:37] <bdmurray> tedg: doko is looking into it some and so am I
[20:38] <popey> tedg: bdmurray i have 4 devices, and on the one I have used most, it has "Diagnostics : Sent" in settings
[20:38] <bdmurray> tedg: I'm trying to get it sorted it out
[20:39] <popey> http://paste.ubuntu.com/7620032/ what I see from grepping whoopsie
[20:39] <bdmurray> Network connection found that may be a paid data plan.
[20:39] <bdmurray> it only uploads on wifi
[20:39] <popey> tedg: ^
[20:39] <tedg> bdmurray, Ah, cool. It'll be interesting to hear what that issue is :-)
[20:40] <tedg> bdmurray, Is there a way to check what it thinks about the network?
[20:40] <bdmurray> tedg: more than what I just said?
[20:41] <tedg> bdmurray, Sorry, didn't realize that was in reference to the log :-)
[20:41] <bdmurray> tedg: it uses network-manager via dbus see https://bazaar.launchpad.net/~daisy-pluckers/whoopsie/trunk/view/head:/src/connectivity.c#L91
[20:42] <bdmurray> ah, okay
[20:42] <tedg> bdmurray, Oh, wow, you should totally use libnm-glib, it'll make your life easier :-)
[20:42] <bdmurray> tedg: sure, I'll add that to the list ;-)
[20:49] <slangasek> wait what
[20:50] <bdmurray> slangasek: ?
[20:50] <slangasek> wasn't libnm-glib what we /were/ using?
[20:50] <slangasek> I thought that was part of the original implementation, and that this was what was causing whoopsie to wake up 20 times a second ;p
[20:53] <ev> Gnetworkmonitor causes the endless wakeups (on a chatty network)
[20:55] <ev> tedg: libnm-glib put me in gvariant hell, if memory serves. bzr log should be somewhat informative, but I'm on a phone.
[20:56] <tedg> Hmm, I'd guess that libnm-glib would take you out of gvariant hell, the code there looks very GVariant-y.
[21:00] <popey> bdmurray: so do you want me to file a bug or something?
[21:01] <bdmurray> popey: no, your crash reports aren't being uploaded because you are not on a wifi connection.
[21:01] <popey> i am ☻
[21:01] <popey> it's incorrectly identified my connection
[21:01] <tedg> British WiFi, not real WiFi :-)
[21:01] <popey> Metric Bits.
[21:02] <popey> wlan0     Link encap:Ethernet  HWaddr 98:d6:f7:62:80:e2   inet addr:192.168.1.110  Bcast:192.168.1.255  Mask:255.255.255.0
[21:02] <bdmurray> popey: try restarting whoopsie then 'sudo service whoopsie restart'
[21:03] <popey> Jun  9 22:03:00 ubuntu-phablet whoopsie[31548]: Could not connect to the system bus: Timeout was reached
[21:03] <popey> (after some restart messages)
[21:03] <npr> how can i contibute to ubuntu ???
[21:04] <ev> tedg: hm, not sure why then :)
[21:04] <popey> npr: http://community.ubuntu.com/contribute/ ☻
[21:04] <tedg> popey, Do you have a 3g data connection as well?
[21:04] <popey> tedg: i do
[21:05] <tedg> Perhaps whoopsie is detecting the first, instead of enumerating them.
[21:05] <npr> how do i finf bugs .....correct them or submit them for evaluation ...
[21:05] <npr> tried once before but couldnt get started
[21:05] <bdmurray> I've also run into bug 1320988
[21:05] <bdmurray> which is why I suggested restaring whoopsie
[21:06] <npr> can anyone suugest how to get inolved ....
[21:07] <trifort> npr: be patient
[21:07] <trifort> npr: go here http://qa.ubuntuwire.com/ftbfs/
[21:07] <trifort> mpr: see if you can make a red package not red
[21:08] <trifort> npr: http://cdimage.ubuntu.com/ is where you get the daily image
[21:08] <Noskcaj> npr, Or if there is any package you want to work on specifically, find it and fix bugs
[21:09] <npr> trifort : whats difference betweend usual iso and daily image
[21:09] <popey> npr: also, look for bitesize tagged bugs and see if you can reproduce and/or fix https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize
[21:09] <npr> Noskcaj  : used linux for some time ...but no particular choice ..
[21:10] <trifort> npr: daily image has the next ubuntu release that isn’t ready for everyone
[21:14] <npr> popey  how to get  sutaible bug to solve form me ???
[21:14] <npr> popey : what are programming skill i need .... i can code in python and c++ ....
[21:15] <npr> popey : done simple web development with php and backend ....
[21:15] <npr> popey : so how to find out a suitable bug ?
[21:16] <popey> npr: take your time and browse those bugs to find one you can fix
[21:16] <trifort> npr: https://bugs.launchpad.net/drizzle/+bugs?field.tag=low-hanging-fruit
[21:17] <tedg> ev, bdmurray, it looks to me like this loop will exit if it finds any paid interface. Thus ignoring non-paid ones. https://bazaar.launchpad.net/~daisy-pluckers/whoopsie/trunk/view/head:/src/connectivity.c#L133
[21:17] <tedg> tedg, I think you need to check what the default interface is, and use that to determine how traffic is being routed.
[21:17] <trifort> npr: but I find it is best to find a bug that you care about
[21:17]  * tedg is talking to himself
[21:18] <npr> trifort : bug to care about ??
[21:18] <trifort> npr: a bug that affects you
[21:18] <npr> trifort : ok
[21:19] <npr> trifort : i  find a bug ... whats the next step ??
[21:20] <trifort> npr: see if you can reproduce it on your machine
[21:21] <tedg> popey, An interesting test might be to remove your SIM and see if all your crash files upload.
[21:21] <tedg> popey, I'm guessing the answer is yes :-)
[21:23]  * popey looks for one of those things for popping out SD cards
[21:25] <tedg> The ironic part about this being the case is that we'd be specifically not getting crashes from people using the phones daily, but instead from those using casually.
[21:26] <popey> http://paste.ubuntu.com/7620234/
[21:26] <popey> online
[21:28] <popey> still doesn't look like it's uploading
[21:28] <popey> i have a weeks worth of crashes in there, 15 of them
[21:34] <tedg> popey, does it say "online" in syslog ?
[21:35] <popey> yup
[21:36] <popey> this worries me, that we haven't been capturing these crash reports ☹
[21:37] <tedg> bdmurray, Any thing else that could be blocking them? ^
[21:39] <bdmurray> popey: ls /var/crash/ ?
[21:41] <bdmurray> tedg: oh, I haven't seen this before - "Unable to find a hardware address"
[21:41] <tedg> bdmurray, I bet popey is hiding it.
[21:42] <tedg> ;-)
[21:43] <tedg> popey, perhaps restart to see if it's a race with oFono ?
[21:43] <tedg> (restart whoopsie)
[21:43] <tedg> Not the whole phone
[21:46] <popey> http://paste.ubuntu.com/7620314/ is my var/crash
[21:46] <popey> tedg: i rebooted the whole phone after yanking the sim
[21:46] <bdmurray> well I get this error 'unable to find hardware address' message too
[21:47] <tedg> popey, Yeah, curious if it can't get your address because whoopsie started before oFono.
[21:47] <popey> ok, restarted whoopsie
[21:47]  * tedg doesn't want to know what "dirty trojita" is in that directory listing.
[21:48] <popey> hJun  9 22:47:20 ubuntu-phablet whoopsie[4282]: whoopsie 0.2.30 starting up.
[21:48] <popey> Jun  9 22:47:20 ubuntu-phablet whoopsie[4282]: Using lock path: /var/lock/whoopsie/lock
[21:48] <popey> Jun  9 22:47:45 ubuntu-phablet whoopsie[4287]: Could not connect to the system bus: Timeout was reached
[21:48] <popey> haha
[21:48] <popey> (email client)
[21:50] <bdmurray> tedg: restarting whoopsie got me past the hardware address message
[21:50] <bdmurray> popey: try '/usr/share/apport/whoopsie-upload-all'
[21:50] <popey> i have done that before..
[21:50] <popey> but thats manual, right?
[21:51] <tedg> bdmurray, I imagine that is because it can't find oFono. Perhaps the upstart jobs need to be adjusted so it doesn't start until after oFono is up.
[21:51] <popey> yeah, its uploading when i run that
[21:51] <tedg> bdmurray, will upload-all block when on a paid connection? Or does it override that as well?
[21:52] <bdmurray> popey: yeah, its manual but there is an upstart job to start it on a .crash file
[21:52] <bdmurray> so if there were to be a new crash and a new .crash all existing crashes should be uploaded
[21:53] <bdmurray> tedg: yes, whoopsie-upload-all is sort of a misnomer it gathers data for all .crash files and touches .upload so that whoopsie will upload them.
[21:53] <bdmurray> tedg: but doesn't actually upload them
[21:54] <popey> in the same way that I can find all of my uploads from the desktop, is there a way to find all my uploads from my device?
[21:54] <tedg> But if popey had run that before it means there should be .upload files, right?
[21:54] <popey> i have run it in the past, weeks ago
[21:55] <tedg> popey, It's in the settings pane
[21:55] <popey> so it is!
[21:55] <bdmurray> tedg: not if it was weeks ago as some of those crashes are newer than that
[21:56] <tedg> Yeah, okay. And they get cleaned up at some point.
[21:56] <popey> no good for me wanting to look at these on my desktop though
[21:57] <popey> cant copy/paste URLs ☹
[21:57] <bdmurray> stand by
[21:57] <tedg> popey, Type it *very slowly* :-)
[21:58] <bdmurray> gdbus call -y -d com.ubuntu.WhoopsiePreferences -o /com/ubuntu/WhoopsiePreferences -m com.ubuntu.WhoopsiePreferences.GetIdentifier
[21:58] <tedg> popey, As a hack the first url sent to the browser is on the command line, so you could probably get it via ps.
[21:58] <tedg> Assuming the browser wasn't running when you clicked on it.
[21:58] <popey> so it is!
[21:58] <trifort> is there a way to visualize circular locks?
[21:58] <popey> whee!
[21:59] <popey> so should I crontab /usr/share/apport/whoopsie-upload-all ?
[21:59] <popey> ☻
[21:59] <tedg> popey, As long as it takes out your SIM at the same time :-)
[22:00] <popey> hah
[22:04] <trifort> given two manifest files, is there a way to print the changelog differences for the whole manifest difference
[22:04] <bdmurray> whoopsie-upload-all should have created .upload files unless whoopsie wasn't running
[22:05] <tedg> trifort, You can diff two directories: diff foo/ bar/
[22:05] <trifort> tedg: yes, did that
[22:06] <trifort> tedg: sorry
[22:06] <trifort> tedg: knowing that about 20 packages have changed, I want to print the changelogs for the 20 changed packages
[22:06] <popey> All reports uploaded successfully
[22:07] <trifort> tedg: I am wondering if a tool exists before making my own
[22:07] <bdmurray> apt-listchanges
[22:08] <tedg> popey, So we had to remove your SIM and restart whoopsie to get a HW address, then run upload-all ?
[22:09] <trifort> bdmurray: okay, thanks for the help
[22:12] <bdmurray> I reported the restart issue as bug 1328285
[22:21] <popey> thanks bdmurray tedg
[23:33] <slangasek> stgraber: do you know a proper way to programmatically get a list of all network interfaces on a system, including those that are currently down?  http://linux.die.net/man/7/netdevice documents that SIOCGIFCONF doesn't include down interfaces, and recommends /proc/net/dev instead
[23:36] <stgraber> slangasek: I usually iterate through /sys/class/net which works fine if you just want a list or want physical interface related kind of information. If you need to query the interface configuration, then you need getifaddrs and it's a whole other kind of worm (also, some most IPv6 info is also in /proc, but ipv4 isn't... yay for consistency)
[23:58] <slangasek> stgraber: context is whoopsie trying to get a mac address to use as a system identifier; this shouldn't be dependent on network interfaces being up