[09:02] <frankban> axw: could you take a look at https://github.com/juju/juju/pull/6354 ? I think I made all the changes suggested, I'd like another +1 before I land it
[09:02] <axw> frankban: looking
[09:02] <frankban> axw: ty
[09:07] <axw> frankban: I've just pushed one comment, but I'm still reviewing
[09:10] <frankban> cool
[09:16] <axw> frankban: done
[09:17] <frankban> axw: thanks, good suggestions
[10:04] <mup> Bug #1629817 opened: [arm64] bad cpu-cores detection <juju-core:New> <https://launchpad.net/bugs/1629817>
[10:39] <voidspace> mgz: ping
[10:40] <voidspace> mgz: hmmmm... unping
[10:40] <voidspace> mgz: was going to ask for vsphere creds, but I see them in cloud-city as usual
[10:50] <rogpeppe> anyone know if there's a way to list all the users that been granted permissions on a model?
[10:51] <perrito666> Morning all
[10:52] <rogpeppe> perrito666: hiya
[10:52] <rogpeppe> perrito666: do you know the answer to the question i just asked, by any chance?
[10:56] <perrito666> Mmm there is iirc wallyworld implemented something like that, can't remember where though
[11:04] <rogpeppe> perrito666: i see "juju users" but that tells me all users for a controller, not a model
[11:05] <perrito666> rogpeppe: something with shares possibly?
[11:05] <rogpeppe> perrito666: "juju commands | grep -i share" doesn't come up with anything
[11:26] <voidspace> mgz: ping about vsphere
[13:01] <voidspace> katco: natefinch: I am likely to be late for standup - daughter has to go to an emergency dentist's appt
[13:02] <natefinch> voidspace: yikes. Hope she's ok
[13:02] <voidspace> natefinch: just toothache, nothing serious
[13:02] <voidspace> natefinch: I'm kind of glad - she still has her baby teeth and it's a good lesson as to why toothbrushing is necessary...
[13:03] <natefinch> voidspace: fair enough :)
[13:14] <perrito666> rogpeppe: sorry I hung on you, bank made me stash my phone under threat of arrest
[13:16] <natefinch> lol argentina
[13:16] <perrito666> natefinch: well see who laughs after tue wig driven dude gets command of your country
[13:17] <natefinch> perrito666: lol
[13:17] <natefinch> perrito666: I was going to say, in my country you can get shot for holding a toy gun in the toy gun aisle of a toy store
[13:18] <perrito666> in my country you can get shot for rand.Rand{}.int()
[13:18] <natefinch> well, using insecure psuedo-random numbers is a capital offense
[13:18] <perrito666> lol
[13:19] <perrito666> natefinch: the reason for phones being forbidden in banks here is because there was this mo of burglars that would tip from inside the bank to outsiders when someone whitdrew large sums of cash
[13:20] <perrito666> (you can see the level of footshooting put into the solution)
[13:20] <natefinch> ahh, so, same reason we take off our shoes at the airport.  Because "this one time...."
[13:20] <perrito666> yup
[13:21] <perrito666> I really hope no one does anything odd with shoes in a bank here, or visiting the banks is going to be very funny
[13:21] <natefinch> very japanese
[14:00] <cholcombe> i need a hand setting a breakpoint on juju.  I've got gdb and dlv installed.
[14:02] <cholcombe> cmd/juju/application/deploy.go deployCharm seems to be what is failing on me
[14:02] <cholcombe> however gdb and dlv don't seem to know how to break on that function
[14:03] <natefinch> gdb is dicey at best, but I've had good experience with delve via editor integration.  I haven't used it via the CLI
[14:04] <cholcombe> natefinch, delve kinda blew me away when i did a funcs command.  over 100K lines of function def's
[14:04] <cholcombe> natefinch, any idea how to point delve at the right breakpoint?
[14:07] <natefinch> cholcombe: use editor integration, it makes things 1000x easier.  What editor do you use?
[14:08] <cholcombe> natefinch, well i'm trying to debug the controller running jujud.  i haven't tried building juju and running locally yet.  maybe that's the way to go?
[14:10] <natefinch> cholcombe: ahh...  delve does have remote debugging capability, which might still be the best way to go. For delve I'm pretty sure you have to build the binary with delve debugging enabled, but I'm not 100% sure
[14:10] <cholcombe> gah
[14:11] <rogpeppe> perrito666: np
[14:15] <natefinch> cholcombe: I might be wrong about that... the docs only mention that if you build with delve it makes the binary "easier to debug"
[14:15] <cholcombe> yeah
[14:15] <cholcombe> i thought gdb could handle this also but it appears to not be able to find anything either
[14:15] <cholcombe> i suspect the jujud binary was built without debugging flags
[14:16] <natefinch> gdb is known to not work well with go
[14:16] <cholcombe> oh ok
[14:16] <cholcombe> the problem is i have a charm which juju for some reason refuses to deploy
[14:18] <natefinch> cholcombe: the best way to debug these things is to start off with the logs..... what does juju do when you try to deploy it?
[14:18] <cholcombe> natefinch, https://gist.github.com/cholcombe973/d0ab4865691d6996d0c3b20578f269ca
[14:19] <cholcombe> charm proof passes and this charm looks like any other charm.  i'm not sure what juju's problem is
[14:19] <cholcombe> i'm running 2.0-rc2
[14:20] <cholcombe> it used to deploy but i don't remember which version it worked on.  probably after i updated to 2.0 beta's it started failing
[14:28] <natefinch> cholcombe: that looks like it might be a bug
[14:28] <natefinch> cholcombe: let me try here
[14:29] <cholcombe> natefinch, yeah none of the beta's or rc's work on this charm.  i don't know what's special about it
[14:29] <cholcombe> natefinch, i also pushed it to the charm store on --channel edge and that also fails
[14:30] <cholcombe> natefinch, juju deploy cs:~xfactor973/gluster-charm-1 --channel edge
[14:33] <cholcombe> natefinch, i did a charm grant everyone on that in case you want to try
[14:34] <natefinch> cholcombe: crud, I just realized the time, I have to run an errand.  Can you try deploying another local charm and see if that works?  It seems unlikely that the contents of your charm would give a "not found" style error
[14:34] <cholcombe> other local charms work perfectly fine
[14:34] <cholcombe> there's something special about this one
[14:34] <cholcombe> i've tried deleting everything in the repo that is unique and it didn't help
[14:35] <natefinch> wacky, ok
[14:35] <natefinch> try removing the dash in the name
[14:36] <natefinch> I gotta run, maybe someone else can help.  Sorry.
[15:25] <babbageclunk> Can anyone help me with a lxd problem?
[15:26] <babbageclunk> I got bitten by this https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1629766 while trying to install something unrelated.
[15:26] <mup> Bug #1629766: Syntax error in /usr/lib/lxd/upgrade-bridge <lxd (Ubuntu):Fix Committed> <https://launchpad.net/bugs/1629766>
[15:27] <babbageclunk> So I did my best to totally remove lxd and the half-configured interfaces that the failed upgrade left behind.
[15:28] <babbageclunk> But now I can't bootstrap to lxd - I get a message saying to run `sudo dpkg-reconfigure -p medium lxd`, but running it doesn't bring up the network config questions it used to.
[15:31] <babbageclunk> It just says "Warning: Stopping lxd.service, but it can still be activated by:
[15:31] <babbageclunk>   lxd.socket
[15:31] <babbageclunk> " and then completes with returncode=0.
[15:47] <rogpeppe> i've factored out some of the juju/worker code from juju/juju so that we can easily reuse it across projects. i made a few changes as i did so - reviews welcome: https://github.com/juju/worker/pull/1
[15:52] <cholcombe> natefinch, i found the problem.  when i deleted the actions.yaml file it started deploying again.
[15:52] <cholcombe> must be bad syntax or something.  juju really needs a better error message for that
[15:56] <mup> Bug #1629912 opened: the provision network IP addresses have to be smaller than the ones on the public network <juju-core:New> <https://launchpad.net/bugs/1629912>
[16:20] <mup> Bug #1629919 opened: destroy-controller fails and a kill-controller is required. <juju-core:New> <https://launchpad.net/bugs/1629919>
[16:39] <alexisb> dooferlad, ping
[16:39] <alexisb> or voidspace
[16:50] <alexisb_> dooferlad or voidspace ping
[17:05] <voidspace> alexisb_: pong
[17:06] <alexisb_> heya voidspace
[17:06] <alexisb_> just quick q for bug triaging
[17:06] <alexisb_> https://bugs.launchpad.net/juju-core/+bug/1629912
[17:06] <mup> Bug #1629912: the provision network IP addresses have to be smaller than the ones on the public network <juju-core:New> <https://launchpad.net/bugs/1629912>
[17:06] <alexisb_> ^^^ looks like an ip ordering issue which is a known bug?
[17:07] <voidspace> alexisb_: that's what it sounds like, although it's unclear
[17:07] <voidspace> alexisb_: I didn't know we had an IP ordering bug!
[17:07] <alexisb_> hmm, ok :)
[17:08] <alexisb_> I will give ti to rick for now then
[17:24] <bdx_> hows it going all?
[17:25] <bdx_> is there a way to specify what subnet juju bootstraps to?
[17:26] <mup> Bug #1629912 changed: the provision network IP addresses have to be smaller than the ones on the public network <juju-core:New> <https://launchpad.net/bugs/1629912>
[17:28] <hatch> is there a way to get the juju controller and model uuid from the cli?
[17:30] <alexisb_> juju show-model
[17:30] <alexisb_> juju show-controller
[17:30] <alexisb_> is that what you were asking hatch?
[17:31] <hatch> alexisb_: how embarassing
[17:31]  * hatch slowly backs away and closes the door on his way out
[17:31] <hatch> :D
[17:32] <alexisb_> :)
[17:34] <perrito666> hatch: isn't this where your fellow contrymen say their most iconinc catchphrase?
[17:34] <hatch> perrito666: lol
[17:50] <mup> Bug #1629951 opened: cannot specify subnet to  create controller in on bootstrap <juju-core:New> <https://launchpad.net/bugs/1629951>
[18:32] <gQuigs>  new to Go.. how can I build/install juju 1.25?  the instructions seem geared towards trunk...
[18:36] <natefinch> gQuigs: after getting the code, git checkout 1.25 (or juju-1.25.6 for the latest 1.25 release)
[18:36] <natefinch> gQuigs: you can download/install 1.25 on many machines... you probably don't need to build it unless you want to hack on it
[18:37] <gQuigs> natefinch: I need to test a 1.25.6 fix that might break stuff
[18:37] <natefinch> gQuigs: valid :)
[18:37] <gQuigs> a binary build of 1.25.6 would be fine, but I haven't found one
[18:38] <natefinch> gQuigs: https://jujucharms.com/docs/1.25/reference-releases
[18:39] <natefinch> gQuigs: it's hard to find if you don't know how to get there (and even if you do it's like 4 clicks)
[18:39] <natefinch> gQuigs: scroll down to "Proposed"
[18:40] <gQuigs> natefinch: I have actually found that, but the Proposed branch hasn't moved to include the fix I'm looking for (at least according to the PPA) - https://launchpad.net/~juju/+archive/ubuntu/proposed?field.series_filter=xenial
[18:40] <natefinch> gQuigs: ahh, bummer
[18:41] <gQuigs> but I never tried the centos (tar.tz) builds.. could they be newer?
[18:42] <natefinch> I'm sure they're all built off the same codebase
[18:44] <gQuigs> yup, confirmed that, all the same older version :(
[18:45] <natefinch> gQuigs: building juju really isn't hard: http://pastebin.ubuntu.com/23271348/
[18:46] <natefinch> gQuigs: lines 4-8 are just setup... after that, rebuilding just requires go install ./...  (which means build everything in this directory and all subdirectories)
[18:46] <gQuigs> ah, looks like I got most of that, except for the go get launchpad.net/godeps
[18:47] <gQuigs> let's see
[18:47] <natefinch> ahh yeah, you need godeps... that sets all the repos juju depends on to the correct revisions
[18:48] <natefinch> If you want to run the tests, you'll need to install mongo (yes, it's terrible, I'm sorry) ... but if you just want to build and run, you don't need it.
[18:54] <gQuigs> well, it worked, but maybe I'm just blind, but how do I actually run it?
[18:54] <natefinch> haha
[18:54] <natefinch> so the binaries get put in $GOPATH/bin
[18:54] <natefinch> juju and jujud
[18:55] <gQuigs> yea, they didn't end up there...
[18:55] <natefinch> oh uh hmm
[18:55] <gQuigs> maybe I should try it again.. I already had already tried to get juju installed...
[18:56] <natefinch> alternatively, from the root of the repo, you can do go build ./cmd/juju and go build ./cmd/jujud and it'll put the binaries in the current directory
[19:15] <gQuigs> natefinch: could this be a difference between go on trusty vs xenial?  (sorry forgot to mention I'm on trusty)
[19:26] <gQuigs> ahh.. blah.. do I have to manually install go 1.6?
[19:29] <natefinch> gQuigs: what does go version say?
[19:30] <gQuigs> go version go1.2.1 linux/amd64
[19:30] <natefinch> oh yeah, that won't work
[19:30] <natefinch> I mean, it might work in 1.25
[19:30] <natefinch> but it really should be 1.6
[19:30] <gQuigs> yea, I just installed go1.6 manaully
[19:30] <gQuigs> will try again
[20:11] <thumper> morning all
[20:11] <alexisb_> morning thumper
[20:27] <gQuigs> thanks a billion for your help nate!
[20:27] <gQuigs> (it's working now)
[20:28] <katco> thumper: morning tim. here, start the day with a fresh cup of easy review: https://github.com/juju/charm/pull/224
[20:29] <thumper> katco: shipit
[20:29] <katco> thumper: ta
[20:30] <katco> thumper: will have a series of these soon... maybe only 1 more based off the pr you have already reviewed
[20:32] <natefinch> gah, is there no way to juju login without it being interactive?
[20:40] <natefinch> thumper: do you know about login/logout?  This code is a mystery to me...
[20:40] <thumper> as in the CLI?
[20:40] <thumper> no
[20:40] <thumper> from the apiserver, yes
[20:41] <natefinch> thumper: yeah. cli.... there's a bug, but I can't even really find where we're prompting for a password...
[20:56] <gQuigs> heh.. agent-streams: local works :)
[21:04] <alexisb_> thumper, I assume you are ditching the bug scrub call?
[21:04] <thumper> yeah
[21:04] <alexisb_> which is fine by me, means i can find some lunch
[21:04] <thumper> ok
[22:01]  * thumper recalls a bug about what he is looking at
[22:10] <mup> Bug #1630029 changed: models should inherit vpc-id from controller  <juju-core:New> <https://launchpad.net/bugs/1630029>
[22:14] <alexisb_> wallyworld, you around?
[22:14] <wallyworld> alexisb_: yes, otp
[22:14] <katco> wallyworld: ohai... thought you were on national holiday. we can still do our 1:1 if you like
[22:14] <wallyworld> one sec
[22:15] <perrito666> wallyworld: welcome back
[22:15] <wallyworld> katco: ok, one sec
[22:18] <wallyworld> alexisb_: sorry, free now, did you have a question?
[22:19] <mup> Bug #1630029 opened: models should inherit vpc-id from controller  <juju-core:New> <https://launchpad.net/bugs/1630029>
[22:19] <alexisb_> wallyworld, yes, thumper and I do: https://bluejeans.com/5036865018
[22:22] <thumper> wallyworld:  https://bugs.launchpad.net/juju/+bug/1629089
[22:22] <mup> Bug #1629089: API Login ACL response values differ from CLI <juju:In Progress by thumper> <https://launchpad.net/bugs/1629089>
[23:22] <perrito666> axw: lemme know if https://github.com/juju/juju/pull/6321#pullrequestreview-2234618 suits what you asked so I can merge this
[23:39] <axw> perrito666: LGTM, thanks
[23:39] <perrito666> tx axw


[09:42] <tjaalton> tseliot: have you seen patches for 5.6 support for nvidia? just a heads up, but at least 390 fails like here https://launchpadlibrarian.net/466479407/buildlog_ubuntu-focal-amd64.linux-restricted-modules-5.6_5.6.0-2.2_BUILDING.txt.gz
[09:43] <tseliot> tjaalton, are we moving to 5.6?
[09:43] <tjaalton> I'll create an oem kernel based on 5.6 but it's ppa-only for now, and having nvidia support isn't time critical yet
[09:44] <tjaalton> for new enablement yes
[09:44] <tjaalton> eventually
[09:44] <tjaalton> oem 5.4 is just temporary
[09:46] <tseliot> I didn't know we would have 5.6, so I didn't really look into that
[09:46] <tjaalton> no worries
[09:46] <tjaalton> but keep it in mind for the next upload if possible :)
[09:46] <tjaalton> to focal
[11:53] <tseliot> sure


[02:39] <psusi> is there a way to get polkit to retain the user home dir?
[04:57] <pitti> Good morning
[07:12] <dholbach> good morning
[07:56] <didrocks> doko__: hey, seb128 and I looked at google-mock for respecitively 30 min and 1h without finding out how to fix the google-mock FTBFS (pthread failures). Tried to add various -pthread (already included) before/after the linkage, tried to look if upstream has anything as well, tried to compare with debian, but the FTBFS is there as well, various google search… do you think you can give us an hand?
[07:59] <didrocks> tvoss: FYI ^
[08:00] <tvoss> didrocks, thanks
[08:11] <czajkowski> aloha
[08:11] <czajkowski> If I buy a brand newlaptop to wipe and install Ubuntu on it, will I run into any issues with secure boot?
[08:12] <czajkowski> looking at buying a X1 Carbon and just want to check to see if there is anything I should avoid
[08:12] <hyperair> ugh x1 carbon
[08:12] <hyperair> no ethernet.
[08:17] <czajkowski> oh now never even thought about that or need for one
[08:17] <czajkowski> altough it can be nice to have as a back up
[08:18] <czajkowski> bugger
[08:19] <hyperair> yeah you'll have to go out and get a USB-3 dock, or ethernet dongle
[08:19] <czajkowski> aye you can get one via  a USB adaptor
[08:19] <hyperair> it's still going to be capped at 100BaseT though
[08:20] <hyperair> USB-3 ethernet dongles are incredibly hard to find
[08:20] <hyperair> (at least here in singapore)
[08:21] <czajkowski> nods gotcha
[08:21] <czajkowski> am more concerned over the secure boot issues I may run into
[08:21] <soren> If ethernet is an emergency backup (ie wifi is the normal connection type), being capped at 100 Mbps doesn't sound like a big issue.
[08:24] <czajkowski> soren: more of a plan B back up
[08:35] <xnox> czajkowski: if you use iso or dd the iso onto usb stick, it should all just work. You must be able to disable secure boot using bios/firmware screens.
[08:43] <greyback> czajkowski: quoting the wiki page, SecureBoot might probably work. https://help.ubuntu.com/community/UEFI#SecureBoot
[08:43] <greyback> czajkowski: and this person looks to have had success: https://x1carbon.wordpress.com/2012/10/16/install-linux-on-lenovo-x1-carbon/ - tho it may have been an earlier model
[08:45] <greyback> http://vasilezaremba.com/installing-ubuntu-12-10-on-lenevo-x1-carbon/ too
[08:50] <czajkowski> xnox: greyback cheers
[08:50] <greyback> happy buying!
[09:00] <infinity> czajkowski: Several of us have Carbons, and they seem to work just fine.
[09:00] <infinity> czajkowski: (Not I, but many others)
[09:40] <seb128> zul, infinity, mdeslaur: hey, does one of you plan to merge apache2 on Debian? there is a bunch of packages in the archive depwaiting on dh-apache2 which is a new helper shipped in the current Debian version
[09:45] <cjwatson> If you do, then be aware that the Apache 2.4 transition is a large and complex one
[09:45] <cjwatson> I think we probably ought to take it, but somebody needs to actually manage that transition
[09:46] <cjwatson> cf. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661958
[09:47] <seb128> cjwatson, thanks, I was not planning to ... which is why I pinged the people who touched apache2 last ;-)
[09:47] <seb128> but good to be aware that it needs planning
[09:47] <cjwatson> Sure, which is why I didn't specifically address my comment to you :-)
[09:50] <seb128> ;-)
[09:52] <seb128> jamespage, doko, whoever looks after java: jarjar in saucy depwait on libasm4-java which is in universe, want to file a MIR for this one? ;-)
[09:54] <pitti> @pilot in
[09:54] <infinity> seb128: I was thinking of merging and starting the transition after Alpha1, but it depends on how far Debian's gotten (or how many patches there are in the BTS), since I don't particularly want to do the whole thing myself.
[09:56] <seb128> infinity, ok, no hurry, as said I just noticed that a few packages are depwaiting on it in saucy ... but we can as well wait for Debian to do a bit more of the heavy lifting ;-)
[09:57] <infinity> seb128: *nod*... We should definitely do it this cycle, I'll keep an eye on it and start it when it seems sane.
[10:06] <pitti> cjwatson: oh, you are handling the casper sponsoring? I was just about to do it, but saw your approval
[10:07] <pitti> cjwatson: ah no, that was -cdimage, not the casper branch, nevermind
[10:46] <pitti> mvo: hey Michael, how are you?
[10:47] <pitti> mvo: there's a bunch of updates in lp:software-properties, is that good for uploading, or do you know of blockers?
[10:50] <pitti> mvo: it works fine here after some basic testing, at least
[11:04] <mvo> pitti: I think its fine, go ahead and upload (I can do that too later if you want)
[11:37] <tvoss_> pitti, ping
[11:50] <pitti> mvo: done
[11:50] <pitti> tvoss_: hey
[11:51] <tvoss_> pitti, hey there :) I'm looking into a VT_SETMODE ioctl resulting in an Input/Output error
[11:52] <tvoss_> pitti, the behavior people are describing hints towards a race, but I'm not a 100% convinced
[11:53] <tvoss_> is there any way to get a little more information about the cause of the error
[11:53] <tvoss_> ?
[11:53] <cjwatson> The notes in the comments at the top of /lib/udev/console-setup-tty may be helpful
[11:53] <cjwatson> (or may not)
[11:54] <pitti> tvoss_: first time I hear about VT_SETMODE, I'm afraid; what's the context there?
[11:56] <tvoss_> pitti, Mir has to adjust the vt mode to process-controlled (as opposed to kernel controlled), and specify some callbacks to manage its state on vt switches
[12:02] <cjwatson> I wonder if you're accidentally trying to perform that ioctl on a hung-up tty
[12:05] <cjwatson> TBH for undocumented console ioctl failures you generally have to either attempt to divine the problem from kernel source or else rebuild the kernel with extra printk debugging
[12:16] <apw> cjwatson, it is possible i have another report of linux-image-generic not being installed after install, do you know of any cases of this still occuring, and if it is would that likely be ubiquity ?
[12:17] <cjwatson> apw: I don't know of one, but I'm not sure I would :)
[12:17] <cjwatson> apw: Find out first whether it was a serverish or a desktopish install
[12:18] <apw> cjwatson, they are saying "live USB key" and it is a laptop they are installing, so i belive it is a desktop job
[12:18] <apw> bug #1172852
[12:18]  * apw tries to raise the reporter on irc as well
[12:20] <smb> Since it says life usb key. I would assume not-server
[12:21] <cjwatson> I'd suggest getting /var/log/installer/syslog and perhaps also /var/lib/dpkg/status then
[12:21] <doko> didrocks, Daviey, Laney: did one of you ping me about the ipxe ftbfs? looks like an issue in ipxe, so the proposed fix seems to be ok
[12:21] <Laney> I don't have any memory of that
[12:21] <Laney> doesn't mean that I didn't ...
[12:22] <didrocks> doko: neither did I, I pinged you about google-mock vs pthread
[12:22] <doko> didrocks, can't remember that one either ;)
[12:23] <didrocks> doko: here it is: http://irclogs.ubuntu.com/2013/06/24/%23ubuntu-devel.html#t07:56 :)
[12:23] <Laney> btw, I'm trying gtk3 with 4.7 to see if that really is it
[12:26] <doko> didrocks, you need to build libgtest with -pthread, not just the executables for the unittests
[12:26] <seb128> Laney, ?
[12:26] <Laney> yes?
[12:26] <seb128> Laney, gtk3 works fine with gcc 4.8 before those linaro changes got merged in
[12:26] <Laney> you narrowed it down more?
[12:26] <seb128> well, to one revision
[12:27] <seb128> not sure how gcc 4.7 is going to be useful
[12:27] <doko> well, to one gcc upload
[12:27] <Laney> it's useful because you can upload using that on armhf in the interim
[12:27] <seb128> right, sorry "revision" -> "upload"
[12:27] <seb128> Laney, -O0 workaround it
[12:27] <seb128> so we can use that was well
[12:27] <doko> did you narrow it down even more?
[12:27] <seb128> doko, ^ just that -O0 works
[12:27] <seb128> -O1 or -O2 breaks
[12:27] <seb128> not sure how to narrow it further down
[12:28] <doko> is there a single test case which you can run?
[12:28] <doko> well, it's the game about combining O0 and O2 object files until you find the offending one
[12:28] <seb128> not really, it's basically "build libgtk.so, run one of the tests, it fails with new gcc"
[12:28] <seb128> I don't know how to do that
[12:29] <seb128> and libgtk has a full stack of object files
[12:29] <seb128> I tried to "touch .c" on random sources
[12:29] <seb128> but that feels like random poking going nowhere
[12:29] <doko> I know, it's a time consuming task ...
[12:30] <doko> did you open an issue for that?
[12:30] <seb128> no, I will do it in a bit, I was waiting to get a bit more details
[12:30] <seb128> e.g trying to optimization
[12:30] <seb128> I poked enough around to open a bug with some content at this point
[12:31] <cjwatson> Bisecting -f options can help too, although it's not always the case that you get a clean bisection there
[12:31] <seb128> I'm not sure I will be able to spend more time on that anyway, I almost spend a day on it already
[12:31] <seb128> cjwatson, you mean?
[12:32] <cjwatson> I mean that much of the difference between -O0 and -O1 can be controlled in more fine-grained ways using a variety of -ffoo options
[12:32] <seb128> oh
[12:32] <seb128> is the list of options described somewhere?
[12:33] <cjwatson> http://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/Optimize-Options.html#Optimize-Options
[12:33] <seb128> thanks
[12:33] <mlankhorst> brrr, rebuilding mesa 4 times again locally because the sru was preempted by a security update :/
[12:33] <cjwatson> Like I say, it isn't always perfect - I don't think everything's independently controllable, and some of the optimisation options interact
[12:33] <cjwatson> But it can sometimes help
[12:33] <apw> cjwatson, confirmed it is a live cd install on a normal system, i've asked them to attach the said files
[12:34] <cjwatson> ok
[12:34] <pitti> didrocks: hm, the bunch of unity-ish uploads in https://launchpad.net/ubuntu/raring/+queue?queue_state=1 look like an error in the autolanding? or was that actually supposed to be a massive SRU?
[12:34] <doko> right, bisecting options options helps too, but it won't help much finding the location
[12:35] <seb128> cjwatson, doko, Laney: I will try to poke around a bit more, but that seems like a time sink work and I've already spend more time on than that I should (or rather delayed touch work that I should be doing) ... I might just end up filing the bug and build gtk with -O0 on armhf as a workaround
[12:36] <seb128> pitti, that stack seems about right
[12:37] <seb128> pitti, they are all components from a stable series with SRU bugs manually pushed (I think sil2100 worked on that landing)
[12:37] <doko> pitti, infinity: I was wondering if we can build locales again from the eglibc sources, or what would be needed for that
[12:37] <pitti> seb128: ok, thanks for confirming (just saying, the SRU team won't be happy about that)
[12:37] <seb128> pitti, why wouldn't them?
[12:38] <pitti> doko: I think we can actually; this was originally split back in the ancient days for adding locale editing support to LP, but this won't happen, and it's not very important
[12:38] <pitti> doko: we have a couple of patches to locales which would need to go to eglibc then, plus our modificaitons to locale-gen, but not much else really
[12:38] <seb128> pitti, it's only 10 sources, we do land more than that manually when we do e.g a GNOME minor releases round or when KDE does a point release update
[12:38] <pitti> seb128: there's no debdiff nor changelog in the queue, so a bit hard to review
[12:39] <pitti> anyway, it just caught my eye during my sponsoring shift
[12:39] <seb128> pitti, yeah, that's a known issue, but the staging ppa which is used for copy should have the diff
[12:39] <doko> pitti, cool, can you coordinate with infinity so that he may get these included upstream in 2.18 maybe?
[12:40] <pitti> doko: ah, maybe the eglibc maintainers are more open to that; I sent all our locale changes to glibc, and some were even accepted, but you know Ulrich.. :)
[12:40] <pitti> doko: does eglibc have a separate bug tracker? I can re-send them there
[12:41] <doko> pitti, no, but carlos o donell is now doing glibc release management
[12:41] <pitti> most of our patches are just taken from Debian's eglibc package, but we have some 5 extra
[12:41] <apw> cjwatson, i assume if we see the below, this is not good:
[12:41] <apw> Jun  7 12:16:27 ubuntu ubiquity: Removing linux-generic ...
[12:41] <apw> Jun  7 12:16:27 ubuntu ubiquity: Removing linux-headers-generic ...
[12:42] <cjwatson> apw: Probably not but I have a policy of not looking at partial log fragments :-)
[12:43] <apw> cjwatson, it is attached in full to the bug
[12:43] <apw> :)
[12:44] <cjwatson> apw: Ah, that's bug 1070427 then
[12:44] <cjwatson> Not fixable without a 12.10 point release ...
[12:44] <apw> cjwatson, ahh ok, nasty
[12:45] <doko> didrocks, are you looking at google-mock?
[12:47] <pitti> @pilot out
[12:51]  * dholbach hugs pitti
[13:05]  * pitti hugs dholback
[13:23] <didrocks> dholbach: I tried to build libgtest (the one embeeded) with -pthread without any luck, if you can give a look, that would be nice :)
[13:23] <didrocks> pitti: no, it's a SRU that has been reuploaded 3 times because the package went invalid after a while (the syncs)
[13:23] <didrocks> pitti: it's indicators + unity srus
[13:24] <dholbach> didrocks, are you sure you wanted to ping me about it? :)
[13:24] <didrocks> dholbach: no, too many "d" on this channel!
[13:24] <didrocks> "oh wait" :)
[13:24] <didrocks> doko: I tried to build libgtest (the one embeeded) with -pthread without any luck, if you can give a look, that would be nice :)
[13:25] <dholbach> yeah, thought so - the other German whose nick starts with a'd' :)
[13:25] <dholbach> or "the other guy in Berlin..." :)
[13:25] <didrocks> dholbach: I was close you will notice!" :)
[13:25] <dholbach> didrocks, if it's early enough, I'll meet doko on Friday - I can let him know there ;-)
[13:26] <didrocks> dholbach: ahah, let's plan on that then! :)
[13:26] <dholbach> brilliant
[13:26]  * didrocks hugs dholbach
[13:26]  * dholbach hugs didrocks back
[13:33] <seb128> doko, Laney: ok, I opened https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1194123
[13:44] <mlankhorst> can some core dev sponsor xxv-intel-lts-raring and mesa-lts-raring from http://people.canonical.com/~mlankhorst/lts-raring.tar ? Keep in mind that you need to use dpkg-buildpackage with -v to get all the changes from the previous lts-raring entry, else the sru will get rejected again :/
[14:04] <tseliot> mlankhorst: if you build the sources with "-v" for me, I'll gladly get your sources, sign them and upload for you
[14:06] <mlankhorst> tseliot: the .changes in there should be correct
[14:07] <tseliot> mlankhorst: ok, let me have a look
[14:10] <pitti> fginther: so I was mostly wondering whether the ap-gtk tests should run at package build time or not
[14:11] <pitti> fginther: doing so requires xvfb; it currently works, but it's rather slow and requires disabling one check
[14:11] <fginther> pitti, I wouldn't go done that path of running xvfb during package build...
[14:11] <pitti> fginther: if not, I'd like them to run at least for merge proposals (CI); but I don't know how to integrate them there
[14:12] <pitti> fginther: but do you agree to the part of integrating it into "make test"/"ctest"? that makes local development a whole lot simpler
[14:12] <fginther> pitti, for lp:autopilot, the tests were split into 'unit' and 'functional' tests. The unit tests run during package build and don't require any X interfaces.
[14:12] <pitti> fginther: ok, I don't have that for ap-gtk, as by its nature all tests are integration tests
[14:13] <fginther> pitti, I do agree an making it easier for devs to run.
[14:13] <fginther> hmm
[14:13] <pitti> fginther: or rather, as long as we can do blackbox testing through the AP interface, I'm not that keen on encoding particular implementation details in unit tests
[14:14] <pitti> fginther: I can just change the dh_auto_test rule to not run the tests, so we can keep ctest without having to run it during package build
[14:14] <doko> didrocks, could you point me to your fix attempt?
[14:14] <pitti> fginther: so if we don't run them during package build, how can I ensure that they run for MPs?
[14:15] <fginther> pitti, we should be able to add them to the daily-release integration testing
[14:15] <didrocks> doko: I have a source in /tmp/, want me to upload it? I tried several autoreconf and modification of Makefile.am, but not sure that will give you anything
[14:15] <didrocks> doko: basically, adding -pthread at multiple place and trying to executed the failing g++ line manually, switching the args
[14:15] <fginther> pitti, we also have ways to run them during MP, but it's a bit clunky right now, so we only do it for a handful of packages
[14:16] <pitti> fginther: hm, isn't that the main point of doing CI?
[14:16] <pitti> fginther: in this case, perhaps we should keep the tests during package build for the time being? that'll run them in MPs too (I got a reject the first time, then added the missing build deps, and it succeeds now)
[14:16] <fginther> pitti, the ci infrastructure is geared toward unit tests. running UI tests requires a lot of infrastucutre
[14:17] <pitti> fginther: ah, I thought we'd use the same infrastructure for upstream CI as for the distro autolanding
[14:17] <pitti> (as they are essentially the same test suites)
[14:17] <fginther> pitti, we're not there yet :-)
[14:17] <pitti> fginther: understood :) (sorry, I'm still not quite familiar with all the details behind that)
[14:18] <fginther> pitti, I'll take a look at the MP and do some testing through jenkins. If there are no issues, there is no reason not to run the tests during package building
[14:18] <pitti> fginther: so it sounds like we should keep the "xvfb-run ctest during package build" for now? It succeeds for the full test suite (https://code.launchpad.net/~pitti/autopilot-gtk/add-tests/+merge/171036)
[14:18] <fginther> pitti, yes. I'll make sure it runs, then comment in the MP
[14:19] <pitti> fginther: thanks (both MPs have links to jenkins build, FTR)
[14:19] <pitti> fginther: locally I test in sbuild, that should be reasonably similar
[14:20] <fginther> pitti, thanks. I'll get back to you
[14:20] <pitti> fginther: ack, thanks to you
[14:20] <tseliot> mlankhorst: uploaded
[14:21] <mlankhorst> thanks
[15:01] <seb128> Laney, sorry, not sure how much that spammed
[15:01] <seb128> stupid website/firefox
[15:01] <Laney> a lot
[15:01] <Laney> :P
[15:01] <seb128> I selected one line to copy but it seemed to have taken the whole file
[15:02] <seb128> and IRC isn't clever enough to limit the paste
[15:02] <cjwatson> It didn't spam everyone; I only saw you quitting
[15:02] <seb128> cjwatson, it was on #ubuntu-desktop
[15:02] <cjwatson> Ah
[15:02] <cjwatson> Your IRC client might not be clever enough.  irssi is :-)
[15:02] <seb128> I'm writting here because I'm not sure if spamming is still ongoing :p
[15:26] <smoser> how often does the auto sync occur ?
[15:28] <mlankhorst> bdmurray: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/1100586 .. irony
[15:29] <cjwatson> smoser: Every six hours; currently disabled, see https://lists.ubuntu.com/archives/ubuntu-release/2013-June/002422.html
[15:29] <xnox> smoser: if it's already available at pad.lv/d/package, and is needed, then you can use syncpackage command ;-)
[15:32] <smoser> xnox, yeah, i was aware i could do it. just didn't know why it didn't just happen.
[15:32] <smoser> i think i'm ook waiting until tuesday morning.
[15:33] <smoser> thanks cjwatson xnox
[15:35] <bdmurray> mlankhorst: it'd be ironic if I were running Quantal, but the description says I was using 13.04.
[15:36] <mlankhorst> ah :p
[15:36] <mlankhorst> just accept I guess
[16:06] <didrocks> cjwatson: hey, small and probably a dummy question. There are tracers tools (they are libs) using lttng to bind mirserver/mirclient to some kernel tracing calls. I put them in a mir-test-tools
[16:07] <didrocks> cjwatson: I, of course, then get those lintian warnings: http://paste.ubuntu.com/5795887/
[16:07] <didrocks> the 3 first are "wanted" (they are not real consumer libs anyway), but the last one shows that dh_makeshlibs is ignoring this package it seems
[16:07] <didrocks> even forcing the call with -pmir-test-tools shows that it doesn't produce the postinst, postrm
[16:08] <didrocks> so apart from making the ldconfig call manually in postinst, postrm, I'm out of ideas, would you know more?
[16:08] <didrocks> (does dh_makeshlibs filters on package name, I tried looking if there was some algorightm like starting with "lib", but didn't get any luck?)
[16:13] <cjwatson> didrocks: Can't you put them in a private directory instead, if they're not meant to be on the system runtime linker path?
[16:14] <didrocks> cjwatson: I think lttng needs them to be on a system runtime path
[16:14] <cjwatson> didrocks: e.g. /usr/lib/man-db/libman.so doesn't cause a problem
[16:14] <didrocks> tvoss: would know more ^
[16:50] <hyperair> ScottK: regarding bug #1193667, would it be too invasive if i could the BPM detection module in an SRU here?
[17:01] <jdstrand> jjohansen: hey, did you figure out a way to install a kernel on the touch image without regenerating it? if so, I can help you test aa3 kernels on mako and grouper
[17:02] <jjohansen> jdstrand: heh I haven't gotten that far yet
[17:02] <jdstrand> jjohansen: if that would be helpful that is.
[17:02] <jdstrand> jjohansen: ack, let me know if I can be of assistance
[17:02] <jjohansen> jdstrand: so no I haven't yes that would be helpful
[17:03] <jdstrand> k
[18:28] <MDesigner> hey guys, who can I contact w/ regards to all things Ubuntu audio? (sound effects, etc)
[18:37] <seb128> MDesigner, hi, try TheMuso or diwic
[18:38] <diwic> MDesigner, hi
[18:38] <fhf> hello all I have a problem with packaging: I need to copy icon to particular dir and I add "cp" to "rules" file http://paste.ubuntu.com/5796280/ but it gives me error "no such file or dir" and it cannot copy icon http://paste.ubuntu.com/5796283/ any1 can help?
[18:44] <tvoss> ScottK, ping
[19:00] <fhf> hm any genius at packing can help?
[19:30] <MDesigner> argh. was in a conversation w/ diwic but he split before I got off the phone. he said I should talk to the design team. so… now who do I contact? :)
[20:09] <hallyn> pitti: hey, do you remember the udev bug which caused debootstrap to leave a udevd running from the install?
[20:10] <cjwatson> Bug 1182540
[20:11] <cjwatson> It wasn't a udev bug in the end
[20:11] <hallyn> oh right.  thanks!
[21:22] <stgraber> cjwatson: meetings minutes are in the moderation queue
[21:22] <stgraber> *meeting
[21:23] <cjwatson> poked
[21:23] <stgraber> thanks


[13:29] <mup> Bug #1980092 opened: maas does not discover platform devices (including NICs) <MAAS:New> <https://launchpad.net/bugs/1980092>