[06:44] <jose> lazypower: hey, thanks for reviewing! I was checking and don't see a MP on the branch atm
[06:51] <jose> oh, there we go
[07:09] <lazypower> Yeah, I was still composing :)
[07:09] <lazypower> There's a few things I had to do to bring it up to spec for continued review, most of which was mentioned previously by Ben
[07:10] <lazypower> If you like i can include those in the MP for you to use as a baseline for the fixes
[07:12] <jose> lazypower: what are those? I can try and fix them now
[07:12] <jose> (already merged the branch)
[07:14] <lazypower> in config-changed you compare using =! instead of -n
[07:14] <lazypower> it should read if [ -n "$SSL" ]; then
[07:14] <jose> fixed that
[07:14] <jose> (fixed everything that's on the comment already)
[07:14] <lazypower> and your PWDIR variable is unbound
[07:14] <lazypower> ah then you should be up to snuff for the charm-run completing, just validate the intent is being performed :)
[07:15] <jose> lemme check then :)
[07:16] <lazypower> I'm going to head out and get some sleep. I'll be around closer to 9AM EST for a review update if its ready
[07:17] <jose> sure, I should be pushing in a minute :)
[09:59] <noodles775> rogpeppe: Hi there. RE you question last Friday, yes requests is a python library you'd need to install. Sorry, I didn't mention that in my paste. I saw you were able to repro the issue in the end though...(with the other persons steps). Great!
[10:00] <rogpeppe> noodles775: the issue should be fixed in trunk now
[10:00] <noodles775> woot :)
[10:29] <eagles0513875_> hey all :)
[10:29] <eagles0513875_> hey fwereade
[10:38] <eagles0513875_> fwereade: are you around?
[10:38] <fwereade> eagles0513875_, yeah, but meeting in a mo
[10:38] <eagles0513875_> fwereade: ok hit me up when you return then it can wait.
[10:39] <fwereade> eagles0513875_, better to ask
[10:39] <eagles0513875_> fwereade: just a quick question for using lxc containers or using juju on my vas i need to use manual provisioning right
[10:39] <fwereade> eagles0513875_, I might see and answer, so might someone else
[10:40] <fwereade> eagles0513875_, those are different things really -- you can experiment locally with lxc/kvm in the local provider, you can experiment on arbitrary machines with manual provisioning
[10:41] <eagles0513875_> ok fwereade but is it going to be a bit tricky though to ensure that even though I'm using manual provisioning that it won't spawn another instance?
[10:41] <eagles0513875_> or want to spawn another instance
[10:46] <fwereade> eagles0513875_, if you're using a manual environment juju never provisions any other instances itself
[10:46] <fwereade> eagles0513875_, you have to add-machine them manually
[10:46] <eagles0513875_> fwereade: ahh ok
[10:47] <eagles0513875_> so basically if i need to deploy another instance of lets say wordpress on a different vps i would need to add the machine but then would it ask me which machine I would like to put it on?
[10:48] <fwereade> eagles0513875_, if you care in detail about placement, you should probably specify it by hand with --to
[10:49] <fwereade> eagles0513875_, otherwise we'll put new units onto clean empty machines hat match the service/environment constraints
[10:49] <eagles0513875_> got it
[10:50] <eagles0513875_> fwereade: it should i think allow you to specify which machine you want to deploy it on even if you already have an instance on it
[10:59] <eagles0513875_> hey all is it possible to install juju on debian?
[11:02] <jamespage> marcoceppi, not having 'default' config is no longer acceptable?
[11:03] <fwereade> eagles0513875_, there's a --to param for deploy/add-unit
[11:03] <eagles0513875_> fwereade: ?
[11:03] <eagles0513875_> oh ok
[11:03] <fwereade> eagles0513875_, that's how you specify what machine to deploy a unit to
[11:03] <eagles0513875_> ahh ok
[11:04] <bloodearnest> heya all, finally figured out my local lxc issuesm in case anyones interested: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1205086
[11:04] <eagles0513875_> fwereade: you can't really do that from the web interface can you
[11:04] <_mup_> Bug #1205086: lxc-net dnsmasq --strict-order breaks dns for lxc non-recursive nameserver <libvirt (Ubuntu):Expired> <lxc (Ubuntu):Expired> <https://launchpad.net/bugs/1205086>
[11:04] <eagles0513875_> fwereade: also is it possible to work with juju on debian
[11:04] <fwereade> eagles0513875_, yeah, I don't think that's exposed there
[11:04] <eagles0513875_> fwereade: which is a shame tbh
[11:04] <fwereade> eagles0513875_, work on machines in the gui is ongoing
[11:04] <eagles0513875_> everything you do on the command line imho should be exposed and usable on the web interface
[11:05] <fwereade> eagles0513875_, they're separate projects, they don't completely lockstep
[11:05] <eagles0513875_> btw fwereade  sorry if I'm interrupting your meeting
[11:05] <fwereade> eagles0513875_, but yeah I understand that position and generally support it ;)
[11:05] <eagles0513875_> fwereade: what would be interesting to see is if juju would become platform agnostic meaning will work on debian or ubuntu
[11:05] <fwereade> eagles0513875_, depends which bits tbh
[11:06] <fwereade> eagles0513875_, you can currently only deploy to ubuntu, but can deploy *from* from win/mac as well
[11:06] <fwereade> eagles0513875_, you never know, the `juju` binary might just work unmodified on debian
[11:11] <eagles0513875_> fwereade: what the person I'm talking to is interested in knowing is if we can deploy stuff to debian based machines.
[11:11] <eagles0513875_> it would be great if that could be done
[11:11] <eagles0513875_> tbh
[11:12] <fwereade> eagles0513875_, it can surely be done, but not without some work
[11:12] <eagles0513875_> fwereade: would be  more then willing to help out with that but i guess i should get familiar with the code first
[11:32] <eagles0513875> fwereade: what would be the best and first steps to get things goign with contributing plus working towards joining your team
[11:33] <fwereade> eagles0513875_, I would start by dpeloying an environment and fiddling with the charm
[12:29] <eagles0513875> fwereade: regarding the above as i just saw this would you recommend I do it with the local provider?
[12:30] <eagles0513875> fwereade: out of curiosity to get juju to work on an ubuntu private cloud
[12:30] <eagles0513875> ubuntu server would need to be setup as MAAS right
[12:36] <eagles0513875> fwereade: i think there is an issue with the documentation for the local provider
[12:36] <eagles0513875> getting an error when i try to bootstrap to the local provider about an ssh key
[12:37] <eagles0513875> and there in the documentation there is no mention of generating an ssh key there
[12:37] <eagles0513875> fwereade: https://juju.ubuntu.com/docs/config-LXC.html
[12:51] <fwereade> eagles0513875, https://juju.ubuntu.com/docs/ has it right at the top
[12:51] <fwereade> eagles0513875, but fwiw the trunk version generates one for you if it can't find one
[12:52] <eagles0513875> in terms of the juju site where would i file a suggestion
[12:52] <eagles0513875> getting started the way it is i wouldnt think to click it as it seems to be a section name for the menu
[12:53] <eagles0513875> i would put getting started as a first menu
[12:53] <eagles0513875> fwereade: brb
[13:17] <marcoceppi> jamespage: yes, if you want a "null" default just use a empty string `default: ""`
[13:17] <marcoceppi> jamespage: It's a W so it's not a critical Juju error, but rather it affects juju tools (ie: GUI, deployer, etc)
[13:17]  * marcoceppi should document what each level of error is for proof
[13:43] <jamespage> marcoceppi, that does not work
[13:43] <jamespage> "" != None with config-get --format=json
[13:47] <jamespage> marcoceppi, btw do you have a mysql charm for trusty yet? we're still using a butchered one in the openstack test lab
[14:05] <eagles0513875> fwereade: i find it a bit strange if one is using a local provider an SSH key is required
[14:06] <eagles0513875> fwereade: it make sense if you are testing on a remote server but in my case i am not
[14:06] <eagles0513875> i guess it should be presented as an option to the user when setting up the local provider
[14:28] <eagles0513875> hey guys is it possible if im running the local provider on my laptop to bypass the need for ssh keys
[14:36] <fwereade> eagles0513875, it's not really -- every difference between the local provider and the others is a source of potential nastiness, and adding a special case to allow people not to use ssh isn't worth it
[14:37] <fwereade> eagles0513875, is there a problem with just running ssh-keygen, or setting authorized-keys[-path] directly?
[14:37] <eagles0513875> fwereade: non no i just find it a bit useless if im running the local provider on the same laptop im on now
[14:37] <eagles0513875> here is the use case im thinking of
[14:38] <eagles0513875> fwereade: what im trying to get at is why not provide users the ability if they are using the local provider to use local host which doesntn require ssh
[14:38] <eagles0513875> and if they want to use the local provider obviously they would need ssh there
[14:38] <fwereade> eagles0513875, because you're not sshing tolocalhost? you're sshing to the containers
[14:39] <eagles0513875> ahhh ok
[14:39] <eagles0513875> that isnt that clear in the documentation
[14:39] <fwereade> eagles0513875, "you need a keypair" is pretty clear, I think
[14:39] <eagles0513875> sorry for the confusion
[14:39] <fwereade> eagles0513875, no worries :)
[14:39] <eagles0513875> fwereade: what isnt clear is what its used for. it just says generate a key pair
[14:40] <fwereade> eagles0513875, the reasons could be better explained, but IMO that's not really appropriate for step-0 introduction
[14:40] <eagles0513875> just have to figure out a way to keep my production private key seperate from the one im going to be generated
[14:40] <fwereade> eagles0513875, what's the concern there?
[14:41] <eagles0513875> with the id_rsa file be appended to?
[14:41] <fwereade> eagles0513875, I don't follow -- you have a private key set up already but haven't got the public key there?
[14:41] <eagles0513875> i think my mind is just out to confuse me today
[14:42] <fwereade> eagles0513875, is it that you have id_rsa in ~/.ssh, but not id_rsa.pub
[14:42] <fwereade> ?
[14:42] <eagles0513875> fwereade: correct
[14:42] <fwereade> eagles0513875, hmm, why would you do that?
[14:43] <eagles0513875> fwereade: i have my private key in there so when i ssh into the vps's i have in production i just have to give the key's password
[14:43] <fwereade> eagles0513875, sure, but where do you get the public key from when you're setting up one of those machines?
[14:43] <eagles0513875> i have the public key saved in a secure location so i then upload it to the server
[14:44] <fwereade> eagles0513875, it's the public key
[14:44] <fwereade> eagles0513875, you can hand it out willy-nilly
[14:44] <eagles0513875> fwereade: ok i have my mind in knots today lol
[14:44] <fwereade> eagles0513875, it's the private key you need to take care of ;p
[14:44] <eagles0513875> id_rsa the private key
[14:44] <fwereade> eagles0513875, yeah
[14:44] <eagles0513875> ok
[14:44] <eagles0513875> i have one of those already in there the public key is on the servers
[14:45] <eagles0513875> if i generate another one will it apend the new private key to the already existing id_rsa
[14:45] <fwereade> eagles0513875, no, I would recommend sshing into one of your servers and extracting your pubkey from authorized_keys
[14:46] <fwereade> eagles0513875, I don't think it's very meaningful to have a private key appended to another?
[14:48] <eagles0513875> fwereade: ok i have both my public and private key pair for my prodcution servers in a secure location
[14:48] <eagles0513875> let me see what happens
[14:48] <fwereade> eagles0513875, so you've got an id_rsa.pub right next to the matching id_rsa now? cool
[14:49] <eagles0513875> ya
[14:49] <fwereade> eagles0513875, note: first time you spin up a local provider will take a long time
[14:49] <eagles0513875> fwereade: whats not making much sense for me is that with out it and just the private key on my laptop ssh keys work fine im just trying to understand why i should have the .pub key there
[14:49] <eagles0513875> especially if i have two private keys in .ssh
[14:50] <fwereade> eagles0513875, I can't see a reason offhand *not* to keep your public key alongside your private one
[14:50] <eagles0513875> fwereade: i dunno why im worrying it gives you a default but also allows you to specify a different file name for the private key when generating
[14:50] <eagles0513875> good point
[14:51] <eagles0513875> also fwereade
[14:52] <eagles0513875> im an idiot lol
[14:52] <eagles0513875> i didnt notice the path when generating the key from within .juju is that it creates the pair in .juju
[14:52] <eagles0513875> and not in .ssh
[14:52] <fwereade> eagles0513875, oh, did we already release a version that creates a keypair?
[14:52] <eagles0513875> fwereade: seems like it
[14:53] <fwereade> eagles0513875, hmm, in that case we ought to be using it
[14:53] <eagles0513875> fwereade: its 1.16
[14:53]  * fwereade grumbles a bit
[14:53] <eagles0513875> fwereade: Installed: 1.16.5-0ubuntu1~ubuntu13.10.1~juju1
[14:53] <eagles0513875> thats whats showing up in my apt-cache policy
[14:53] <eagles0513875> fwereade: probably because im using the ppa
[14:53] <fwereade> eagles0513875, weird, I'm sure that was before we added that, let me take a look
[14:53] <eagles0513875> and installed from the ppa instead of directly from the repo
[14:53] <eagles0513875> anyway i gave it a name to differentiate between the two anyway if it did land in .ssh
[14:54] <fwereade> eagles0513875, just a mo, what did you do? didn't you just get the pubkey from your servers?
[14:55] <eagles0513875> fwereade: no no i was just worried of the key being overwritten when i generated the key for the juju local provider
[14:56] <fwereade> eagles0513875, sure, I'm just wondering why you'd need to generate a new one when you have one already
[14:56] <eagles0513875> good point just like keeping my testing and production stuff seperate
[14:58] <eagles0513875> fwereade: there is something missing in the documentation
[14:59] <eagles0513875> fwereade: do i need to add the pub key to the environments.yaml file for local cuz im getting this error ERROR error parsing environment "local": no public ssh keys found
[15:00] <fwereade> eagles0513875, please tell me exactly what you did
[15:00] <eagles0513875> sudo juju bootstrap
[15:00] <eagles0513875> it doesnt seem to pick up the keys
[15:00] <fwereade> no, what you did to your ssh setup
[15:00] <eagles0513875> fwereade: for juju
[15:02] <eagles0513875> fwereade: when generating the keypair should it end up in .juju if you dont use the default path to .ssh
[15:03] <fwereade> eagles0513875, AFAICT you should not be generating a keypair at all
[15:03] <eagles0513875> ok
[15:03] <fwereade> eagles0513875, you should have got your pubkey and saved it in ~/.ssh/id_rsa.pub
[15:03] <eagles0513875> ok
[15:09] <eagles0513875> fwereade: when one learns to untangle their complex mind setting up juju as the local provider is very very simple
[15:10] <lazypower> I managed to remove my lbox authentication from launchpad in haste, and I'm not positive where it caches its copy of the oauth token. Can someone point me where I need to look to clear its cached authorization?
[15:11] <fwereade> lazypower, I think it's ~/.lpad_oauth?
[15:11] <fwereade> eagles0513875, glad it worked out -- I hadn't considered the private-key-only situation
[15:11] <lazypower> that was it, thank you
[15:11] <fwereade> lazypower, yw
[15:12] <eagles0513875> fwereade: should i file something on launchpad
[15:12] <fwereade> eagles0513875, yes please, that would be very helpful
[15:12] <eagles0513875> fwereade: under juju core?
[15:12] <fwereade> eagles0513875, please
[15:12] <eagles0513875> ok fwereade also any bugs i can help or work on in terms of fixing?
[15:16] <eagles0513875> fwereade: should i run a test on what we just discussed
[15:16] <eagles0513875> and maybe its something i could be mentored in fixing
[15:16] <eagles0513875> fwereade: if you are interested in following this bug https://bugs.launchpad.net/juju-core/+bug/1270858
[15:17] <_mup_> Bug #1270858: possibility of .ssh not having a public key with the private key <juju-core:New> <https://launchpad.net/bugs/1270858>
[15:18] <fwereade> eagles0513875, so, I think the fix is to scan for files with/without .pub suffixes, ignore the ones that don't, and complain about the lack of a keypair (rather than just of a public key)
[15:18] <eagles0513875> fwereade: wouldnt it be good i test with out having the public key first
[15:18] <eagles0513875> to see if it works or does not work cuz right now the issue i filed seems rather vague and not useful
[15:19] <lazypower> fwereade, if lbox fails to propose due to a non existant [branch|repository] is this a sign of a larger problem?
[15:19] <fwereade> eagles0513875, well, the ideal bug report is generally along the lines of "what I did; what I expected; what actually happened"
[15:20] <eagles0513875> fwereade: ok will get more information when i relocate for my ccna class
[15:20] <fwereade> lazypower, hmm, nothing really springs to mind there
[15:20] <eagles0513875> anyway im out for now just deploying wordpress to try things out :)
[15:21] <fwereade> lazypower, is it saying the source or the target doesn't exist?
[15:21] <eagles0513875> fwereade: i have any idea for a really good charm setup. how can I see lets say what the apache charm installs for the web server as apache has about 4 different versions
[15:21] <lazypower> fwereade, http://paste.ubuntu.com/6786390/
[15:22] <lazypower> eagles0513875, that would be in the install hook of the charm you're looking at.
[15:22] <fwereade> lazypower, hmm, I'm not completely sure there -- marcoceppi, have you ever seen that?
[15:22] <fwereade> eagles0513875, lazypower: or more generally inferrable from a variety of hooks, and/or from the config file
[15:22] <eagles0513875> ok
[15:23] <lazypower> Fair enough :)
[15:23] <eagles0513875> fwereade: lazypower not to but in here but could it be the directory /charms/ was moved and the path you are looking for doesnt exist anymore
[15:23] <fwereade> eagles0513875, lazypower: several charms let you choose  different versions to run
[15:24] <lazypower> Its complaining about the remote. My charm is still here locally, but i believe its trying to push to the wrong remote.
[15:24] <eagles0513875> lazypower: check which branch you are on
[15:24] <fwereade> lazypower, hmm, should you be pushing to ~lazypower/charms/mediawiki/trunk perhaps?
[15:25] <lazypower> yeah, i've got an open MP that I was trying to get on codereview
[15:25] <fwereade> marcoceppi, do yu have an immediate answer for lazypower by any chance?
[15:25] <lazypower> thats why i include the parent branch in the config, and i think marco is afk for now.
[15:25] <lazypower> s/config/output listing on pastebin
[15:25] <eagles0513875> fwereade: i have some enhancement suggestions but will need to discuss those with you when i return
[15:27] <fwereade> lazypower, ah, hold on, surely you just need to push to that branch before you first lbox propose -- right?
[15:27] <lazypower> fwereade, https://code.launchpad.net/~lazypower/charms/precise/mediawiki/tests
[15:29] <lazypower> ah ok, now i've got additional legwork. My MP branch and local copy have diverged
[15:29] <fwereade> lazypower, ok, that's pretty unambiguous :)
[15:29] <lazypower> sarcasm? :)
[15:30] <lazypower> and i apologize for my ineptness, i'm still getting comfortable with the toolchain
[15:30] <fwereade> lazypower, no, not at all, the existence of your branch is 100% clear
[15:30] <fwereade> eagles0513875, if I was digging at anyone it was myself ;)
[15:31] <lazypower> haha
[15:31] <fwereade> lazypower, er^
[15:31] <lazypower> You get my seal of approval gustavo
[15:31] <fwereade> lazypower, I'm not gustavo, but I do observe that your error message doesn't include the "precise" I'd expect
[15:31] <niemeyer> lazypower: Heya
[15:32] <fwereade> lazypower, and I was just about to direct you towards the man himself :)
[15:32] <lazypower> O_O
[15:32] <niemeyer> lazypower: Thanks, I suppose :)
[15:32] <lazypower> mind=blown
[15:32] <lazypower> i ran across a post somewhere from you that referenced gustavo and made the mental note it was you... whooops!
[15:33] <lazypower> clearly i need to go back downstairs and not return until i've finished my first cup of coffee
[15:34] <lazypower> niemeyer, gustavo i presume?
[15:38]  * marcoceppi reads scroll back fwereade lazypower
[15:39] <marcoceppi> lazypower fwereade use the -for flag
[15:39] <marcoceppi> lazypower:  lbox propose -cr -for lp:charms/mediawiki
[15:39] <lazypower> marcoceppi, lbox propose -for lp:~blah blah
[15:39] <niemeyer> lazypower: Yeah :)
[15:39] <lazypower> ooohh
[15:40] <lazypower> and good morning
[15:40]  * marcoceppi still has reservations about using lbox for charm reviews, but those are on hold
[15:40] <fwereade> huh, I hadn't read that paste as a problem with the target
[15:41] <marcoceppi> lazypower: can you run bzr info as well?
[15:41] <jose> lazypower: hey, got to fix the postfix charm
[15:42] <marcoceppi> fwereade: I re-read it looks like it's trying to push to lp:~lazypower/charms/mediawiki instead, so maybe the -for flag isn't the issue
[15:42] <marcoceppi> maybe he doesn't have a push branch in bzr yet?
[15:43] <lazypower> jose, great news. Did you put it back in the rev queue? I'll fish it out after i've solved my lbox issue.
[15:43] <jose> lazypower: yeppers! marked it as new
[15:43] <lazypower> marcoceppi, http://paste.ubuntu.com/6786495/
[15:44] <marcoceppi> lazypower: okay, looks good to me. did the -for flag fix this? If not just do `bzr lp-propose lp:charms/mediawiki` and we'll look at lbox for charm reviews tomorrow
[15:45] <lazypower> marcoceppi, i'm working on getting my branch undiverged from whats open as the MP - one moment. Reading up on bzr
[15:46] <eagles0513875> fwereade: will ping you veyr soonn
[15:46] <eagles0513875> i have some nutty but useful ideas :)
[16:10] <eagles0513875> hey fwereade im back
[16:28] <teknico> hi all, got a problem with 1.17 and MAAS, br0 isn't being brought up by Juju when adding a new MAAS machine
[16:44] <marcoceppi> teknico: is the juju agent running on these new machines though?
[16:54] <teknico> marcoceppi, at the end I got this: https://pastebin.canonical.com/103229/
[16:57] <marcoceppi> teknico: is that from cloud-init log?
[17:00] <teknico> marcoceppi, nope, it's the end of the output from trying to start the container manually with "sudo lxc-start --name juju-machine-1-lxc-0"
[17:01] <teknico> in the log there was nothing more than the original error itself
[17:01] <teknico> which was: agent-state-info: '(error: error executing "lxc-start": command get_init_pid failed to receive response)'
[17:02] <teknico> which in turn was caused by br0 missing, at least according to bbcmicrocomputer :-)
[17:03] <marcoceppi> teknico: makes sense, can you paste the cloud-init log file?
[17:03] <marcoceppi> it should be done during lxc install tbh
[17:05] <teknico> marcoceppi, the whole of cloud-init.log? it's 45KB, it'll take a while pasting it :-)
[18:07] <dpb1> marcoceppi: I had a question on that swap charm before I proceed with fixing the review feedback.  You want me to document config options in the readme *and* in the config.yaml?  Seems like I would just be cut-and-pasting descriptions?  Or am I missing what I should be doing there?
[18:33] <marcoceppi> dpb1: config.yaml should have a brief description, readme should have a more detailed explaination as to what the config options does and provide example values
[18:37] <dpb1> marcoceppi: OK
[18:37] <dpb1> thx
[19:52] <dpb1> marcoceppi: in amulet, how do I make use of an existing deployer file?
[19:53] <mgz> dpb1: you can load a deployer config in your script
[19:53] <mgz> it's something like... sec
[19:53] <dpb1> mgz... thx.
[19:53]  * dpb1 waits
[19:54] <mgz> d = amulet.Deployment()
[19:54] <mgz> with open(path):
[19:55] <mgz>   script = yaml.safe_load(f.read) # as f above, whoops
[19:55] <mgz> d.load(script)
[19:55] <mgz> d.setup()
[19:55] <mgz> dpb1: hope that helps
[19:59] <dpb1> mgz: thx, trying now
[20:54] <jose> lazypower: hey, did you get to review the charm?
[20:57] <lazypower> jose: I did not, i was sidetracked upvoting on askubuntu and their rowdy crowd. Let me promote this in my queue and have a look
[20:58] <lazypower> apologies for not getting to it sooner
[20:58] <jose> sure :)
[20:58] <jose> no worries
[21:53] <lazypower> Great work on the revisions jose, I'm going to add my +1 to this charm and place it in another charmers rev queue
[21:54] <jose> awesome, thanks!
[21:59] <lazypower> hey thats good info to have handy mgz, that loads a deployment yaml, ergo a bundle, into amulet?
[22:05] <marcoceppi> lazypower: yeah, if you have a deployer file already in your tests dir, you can bypass all the d.add() stuff and just do d.load()
[22:05] <lazypower> amazingness
[22:05] <jose> hey marcoceppi, if you could also take a look at the postfix charm it'd be great
[22:05] <jose> there you pop up :P
[22:05] <lazypower> I'm writing up my +1 review right now, give me another 5 and i'll have it complete
[22:06] <jose> cool!
[22:06] <marcoceppi> jose: technically a day off today, I'll be in th queue still since lazypower is +1 reviewing it as a "jr charmer"
[22:06] <marcoceppi> so someone from ~charmers will cycle on to it sometime this week
[22:06] <jose> cool thanks!
[22:48] <lazypower> Does juju/maas use a special configuration for DHCP IP Assignment? I know that the local provider allows me to assign a network interface in the environments.yaml if i've opted into configuring my own bridge device.
[22:54] <marcoceppi> lazypower: maas has it's own DHCP server


[00:24] <saiarcot895> Something in the builders doesn't like the 1.1-GB source file (https://launchpad.net/~saiarcot895/+archive/flightgear-edge/+build/5436966)
[00:24] <saiarcot895> Neither this version nor the previous version (which I've retried 3 or 4 times) succeeded, and all failed within minutes
[00:28] <wgrant> Hmm
[00:28] <wgrant> The build farm is really not designed to commonly build packages that large, but it should work.
[00:28] <cjwatson> ensurePresent seems to be synchronous
[00:28] <wgrant> I suspect things are just a bit too heavily loaded atm to fetch all the relevant files within a minute.
[00:29] <wgrant> cjwatson: It is, deliberately.
[00:29] <wgrant> And it has a 60 second timeout atm.
[00:29] <cjwatson> Why deliberately?
[00:29] <wgrant> cjwatson: So we know when it's done.
[00:29] <cjwatson> Well, right, I didn't mean it should be fire-and-forget
[00:30] <cjwatson> Bug 241646, I guess
[00:31] <wgrant> Mm, it doesn't really matter too much.
[00:31] <wgrant> That was mostly from back in the days when it blocked the master.
[00:31] <wgrant> We'd otherwise have to introduce a new call to check if a file existed in the cache, and poll it.
[00:31] <wgrant> Which doesn't seem like an improvement at all.
[00:31] <wgrant> The problem here is just that we set a 60 second timeout, and that's not enough.
[00:31] <wgrant> Even if it were async, we'd still have a timeout, and it would probably still be 60s.
[00:33] <wgrant> I'll increase the timeout to 5 minutes like we have in most other places.
[00:37] <cjwatson> I was thinking of some kind of "still going" callback from the slave, but OK
[00:37] <cjwatson> there does have to be a timeout somewhere, but I would've thought it would be better phrased as "slave download from librarian stalled"
[00:38] <saiarcot895> Perhaps a check to see if the downloaded size has changed?
[00:38] <cjwatson> That's unnecessarily roundabout given that the slave knows what it's downloading.
[00:43] <wgrant> cjwatson: I'm not sure I see the benefit of polling.
[00:45] <cjwatson> I wasn't advocating polling
[00:46] <cjwatson> I don't know quite how to phrase what I want in the buildd slave architecture
[00:47] <wgrant> Unless we radically change the communication architecture, requests have to be initiated by buildd-manager.
[00:47] <cjwatson> But there are two things that might time out: one is master<->slave (e.g. slave falls over), the other is slave<->librarian.  I'm saying those should be independent timeouts; if slave<->librarian times out then it should fail the ensurePresent call (or analogue), but otherwise I'd like it to be able to refresh the master<->slave timeout as long as it's still in progress
[00:48] <wgrant> We probably don't want an unlimited timeout on master<->slave, as slaves more than occasionally break in terrible ways and need to be killed.
[00:49] <wgrant> But it would indeed make sense to have a smaller timeout on the slave<->librarian call
[00:49] <wgrant> And in the normal case terminate it from there.
[00:49] <cjwatson> I get that it's hard with the master using xmlrpclib though, since AFAIK we can't stream a response
[00:49] <wgrant> Right.
[00:55] <cjwatson> We could break the xmlrpc spec and send a response without content-length, and push a byte every so often ... not sure that's the best option :)
[00:55] <wgrant> Heh
[00:55] <cjwatson> it'd require bodging both sides, since neither twisted.web.xmlrpc nor xmlrpclib supports that extension (though it's not unheard of elsewhere)
[00:57] <cjwatson> xmlrpc can't be the best protocol for this
[01:00] <lifeless> s/ for this/./
[03:24] <FourDollars> Hi, I want to register a new project for ibus-chewing, but Launchpad told me that ibus-chewing is already used by another project. And then I open https://launchpad.net/ibus-chewing, there is no such project. Do you know how to fix this?
[03:26] <TheLordOfTime> FourDollars: If it says it exists but you can't see it it *could* be a private project.  If you read the error page: "This page does not exist, or you may not have permission to see it."
[03:26] <TheLordOfTime> (just a thought)
[03:27] <FourDollars> TheLordOfTime: Yes, but it should be a open source project. And should not be a private project.
[03:27] <FourDollars> TheLordOfTime: Is there any way to know who owns this project?
[03:27] <wgrant> FourDollars: I've freed up the name for you.
[03:28] <TheLordOfTime> FourDollars: ask wgrant, who already fixed the problem :)
[03:28] <FourDollars> wgrant++
[03:28] <FourDollars> wgrant: Thanks a lot. :D
[03:29] <wgrant> np
[12:23] <apachelogger> wgrant: can I get a size bump to 10gib on https://launchpad.net/~neon/+archive/kf5-snapshot-weekly please :)
[12:24] <wgrant> apachelogger: Done
[12:24] <apachelogger> wgrant: thank you
[19:00] <KI7MT> Hello, noob question, but I'm trying to locate bugs for a package called yelp-tools  particularly, upstream bugs, but I can seem to fins any bug rpts at all  .. am I not looking in the correct location: https://launchpad.net/ubuntu/+source/yelp-tools
[19:00] <KI7MT> *can't
[19:08] <dobey> https://bugs.launchpad.net/ubuntu/+source/yelp-tools would be where any bugs opened against the package in ubuntu would be, it's not the upstream
[19:09] <dobey> the upstream is probably bugzilla.gnome.org
[19:20] <KI7MT> dobey, Ok, thank you.


[12:42] <leifdk1978> hey guys got some quistions
[17:32] <l3on> mdke: are you there?
[17:32] <mdke> l3on: (In case I'm not around at the moment, please provide a bit of information about what you want and I will respond when I get back)


[00:00] <cnd> micahg: it's not needed for beta
[00:00] <micahg> cnd: nah, happened about an hour ago
[00:00] <micahg> or 2 hours actually :)
[00:00] <cnd> I only want to push it so I don't forget to do it later :)
[00:00] <slangasek> cnd: ftbfs fixes probably still warrant getting in
[00:01] <cnd> slangasek: ok, I'll take your word for it
[00:01] <micahg> cnd: an AA will have to process it in any event since the archive is frozen
[00:01] <cnd> yeah
[00:01]  * cnd fears the retribution of an AA
[00:01] <slangasek> SpamapS: so a year ago, you argued for putting libdbi-drivers in main because libdbi is useless without it (bug #608556)... I would argue that libdbi is worthless even with it and would like to redemote libdbi-drivers so I don't have to touch it for the sqlite demotion. ;)  Any thoughts?
[00:03] <micahg> slangasek: is it too late to take an axe to sqlite?  most of the applications already support sqlite3
[00:03] <micahg> or should we wait for Debian and or P?
[00:04] <slangasek> micahg: define "axe"?
[00:04] <Daviey> slangasek: wait, multiverse can depend on partner?  Is there precedent of that?
[00:04] <slangasek> micahg: you mean wholesale removal?
[00:04] <micahg> slangasek: yes
[00:04] <SpamapS> slangasek: rrdtool and gnucash recommend or depend on libdbi at the moment
[00:04] <slangasek> Daviey: well, I would be more sanguine about allowing a package to depend on a partner package in multiarch than in partner - but yes, ideally we don't want multiarch to depend on partner eithe
[00:04] <slangasek> r
[00:05] <SpamapS> slangasek: and really, libdbi is useless w/o the drivers.
[00:05] <Daviey> slangasek: I think you have multiarch on your brain :)
[00:05] <SpamapS> slangasek: I'd be quite supportive of disabling 'sqlite' tho.
[00:05] <slangasek> SpamapS: sure; that doesn't mean we want to encourage its use or suggest that we support that lousy library
[00:06] <SpamapS> slangasek: there are some very excited folks who use rrdtool's libdbi integration to graph their databases.
[00:06] <slangasek> SpamapS: rrdtool has to link against it if it's to be able to use it at all, so libdbi has to be in main - but I don't think that translates to extending support to libdbi-drivers
[00:06] <slangasek> sure, and that integration would still be there
[00:06] <slangasek> they'd just pull it from universe
[00:06] <SpamapS> slangasek: just.. not usable.. ?
[00:06] <slangasek> where it belongs
[00:06] <slangasek> who are these hypothetical people who don't have universe enabled on their systems? :
[00:07] <slangasek> )
[00:08] <SpamapS> Truth be told I don't like it either.. we could probably make a strong appeal to the upstreams to use libodbc instead.
[00:08] <slangasek> +1
[00:09] <slangasek> in the meantime, what do we do with libdbi-drivers?  I stil think it should be demoted... we've been trying to get sqlite out of main for years already, and this is the last blocker.  We could demote them both, or you could upload libdbi-drivers if you prefer? :)
[00:09] <RAOF> slangasek: Wine just looks like ia32-libs needs to be updated to not depend on lib32v4l-0.  And then add some appropriate depends somewhere.
[00:09] <slangasek> RAOF: oh, that bit
[00:10] <slangasek> add what appropriate depends where?
[00:11] <RAOF> I don't know, but whatever actually depnds on libv4l is obviously going to need to depend on libv4l-0:i386 now.
[00:12] <slangasek> can't be done
[00:12] <slangasek> No way to express a dependency on a foreign package of a specific architecture; ia32-libs should just pick up libv4l for the moment, if it's really needed
[00:13] <micahg> slangasek: wine could be give a dependency i386 only package :)
[00:16] <slangasek> micahg: libv4l-0 isn't i386-only though, and I'm not going to do that horrible trick for a library
[00:24] <micahg> slangasek: well, if there's more than one library, it might make sense to do it in the wine package
[00:27] <infinity> Indeed, wine could depend on wine-libs, or something, an i386 package with dependencies to i386 libs.
[00:27] <infinity> But if we keep perpetuating that hack over and over, it starts making a valid excuse for allowing foo:arch deps. :/
[00:29] <slangasek> oh, it's perfectly *valid* to have foo:arch deps
[00:29] <slangasek> it's just not implemented in dak, soyuz, or dpkgapt.
[00:29] <infinity> Well, yes.  That's what I meant by "allow".
[00:29] <infinity> As in, actually implement it. :P
[00:30] <slangasek> I wish I could make code happen just by giving the bits permission
[00:30] <infinity> *grin*
[00:30] <slangasek> anyway, yeah, it's going to be needed down the line
[00:31] <slangasek> but ia32-libs isn't going to cause it to move up on my priority list any
[00:31] <infinity> Actually, have you considered replacing ia32-libs with a similar "depend on an i386-only metapackage" hack?
[00:31] <slangasek> can't
[00:31] <slangasek> half the libs it depends on aren't multiarch-ready yet
[00:31] <infinity> Or will that not work because ia32-libs is still bi-arch stuff, and things can't find the multiarch versions?
[00:31] <infinity> Yeah.  You beat me to it.
[00:32] <infinity> Though reasoning from the other direction, perhaps.
[00:33] <slangasek> SpamapS: no further comment on libdbi-drivers? :)
[00:35] <SpamapS> slangasek: I hesitate to defend it too much, but I do think its a bit.. funky to have libdbi in main w/o them.
[00:36] <slangasek> SpamapS: are you willing to do the upload to cut out libdbd-sqlite?
[00:36] <slangasek> if not, we don't actually support it - QED ;)
[00:41] <SpamapS> slangasek: yeah that sounds easy
[00:42] <slangasek> ok
[00:42] <Daviey> SpamapS: slangasek is setting up a trap for you.. touched-it-last next cycle ;)
[00:42] <slangasek> darn right I am
[00:42] <slangasek> you'll have to adopt it in Debian
[00:43]  * SpamapS dons his sucker hat
[00:43] <slangasek> I thought the trap was fairly obvious :)
[00:43] <SpamapS> I've tried adopting it in Debian. :-P
[00:43] <slangasek> OTOH, if you get rrdtool to switch to odbc, you can make me do all the work :)
[00:51] <micahg> slangasek: you seem to have evaded my question about dropping sqlite entirely :)
[00:52] <slangasek> micahg: ohright - yes, I don't think it's too late for that provided someone does the work to cull the reverse-dependencies
[00:52] <slangasek> but I wouldn't remove it this late in the cycle without first fixing the revdeps
[00:52] <slangasek> since that's not fair to folks who use those packages
[00:53] <micahg> slangasek: right,there aren't too many rdeps left actually, I have to actually see if any of them only use sqlite and not sqlite3
[01:17] <ScottK> doko: Thanks.
[01:21] <ScottK> jbicha: Is your gnome-shell upload bugfix only?
[01:29] <micahg> slangasek: that's a shame, a 500MB upload for a one line change + changelog (ia32-libs)
[01:35] <Keybuk> I pity the mirrors
[01:42] <slangasek> micahg: I has fast internets now, uploading ia32-libs doesn't bother me anymore :)
[01:43] <micahg> heh
[01:43] <slangasek> I really should've refreshed the contents before upload though... well, I'll do that in a few weeks when skype/partner is sorted
[01:44] <slangasek> or I'll do it when dealing with v4l or something
[01:52] <jbicha> ScottK: no but it's in universe and it has a lot of bug fixes: http://git.gnome.org/browse/gnome-shell/tree/NEWS
[01:55] <jbicha> one issue is that the Gnome Shell in the archives now is almost 2 months old so it's difficult to tell what bugs are still broken upstream
[02:02] <ScottK> jbicha: It needs an FFe.
[02:03] <ScottK> Sounds like something reasonable, but we need to follow the process.
[02:10] <jbicha> ScottK: GNOME 3.2 has a standing FFe
[02:11] <jbicha> I understand that we're in Beta Freeze but GNOME Shell isn't shipped on the CDs
[02:22] <infinity> ScottK: The process doesn't explicitely require bug filing and paper trails, that's just the best way to document things if you can't get an FFe more readily.
[02:22] <infinity> jbicha: And you're right about GNOME's standing FFe, combined with gnome-shell being universe.  I'm fine with it.
[02:33] <ScottK> OK.
[05:39] <pitti> Good morning
[05:39] <pitti> infinity: I meant to sync it, but aborted as I noticed yet another problem in ubiquity first
[05:40] <pitti> ev: I figured out the two remaining ubiquity regressions FYI; I followed up to bug 829186, we need to replace the static "xklavier" import
[06:54] <ricotz> janimo, hello, are you around?
[06:57] <janimo> ricotz, hello, now
[06:58]  * janimo feels this is clutter related :)
[06:58] <ricotz> janimo, yes kind of ;)
[06:58] <ricotz> could you testbuild this on armel http://people.ubuntu.com/~ricotz/gnome-shell/gnome-shell_3.1.4-0ubuntu2.debdiff
[06:59] <janimo> ricotz, sure
[06:59] <ricotz> janimo, thanks
[07:01] <ricotz> janimo, please say so if you want a real package dsc
[07:02] <janimo> ricotz, I'll just apt-get that, I assume it is against latest in oneiric
[07:02]  * janimo just booted up the pandaboard
[07:02] <ricotz> yes
[07:07] <janimo> ricotz, what is happening on armel if no glx is used?
[07:07] <janimo> is functionality missing in GS?
[07:08] <ricotz> janimo, the uncommented parts arent real functionalities, they are just perf related
[07:09] <ricotz> janimo, the configure* changes probably arent needed
[07:09] <janimo> ok
[07:10] <ricotz> janimo, i hope this wont need mutter to be patched too
[07:11] <doko> first compiz crash today
[07:20] <dholbach> good morning
[07:24] <pitti> ev: I have a question for you in https://bugs.launchpad.net/ubuntu-sso-client/+bug/829186/comments/31
[07:29] <janimo> ricotz, GS builds fine with your patch
[07:30] <OdyX> Hmm. It's unfortunate that the Natty PPAs don't support .xz. What else similar can I use ? lzma ?
[07:32] <ricotz> janimo, thanks, i hope it runs too ;)
[07:32] <janimo> ricotz, I do not have my panda set up for graphics testing ATM, but I suppose it should run :)
[07:33] <ricotz> janimo, ok :), thank you
[07:33] <micahg> OdyX: I think that feature was just released to launchpad :)
[07:33] <ricotz> micahg, xz deb compression?
[07:33] <micahg> yeah
[07:33] <OdyX> micahg: okay, but do Natty hosts support data.tar.xz ?
[07:33] <ricotz> nice
[07:34] <micahg> bug 619152
[07:34] <ricotz> OdyX, xz tarball are supported for all pockets
[07:41] <tjaalton> almost to give up.. is there a bzr equivalent of 'git show $sha'?
[07:42] <RAOF> tjaalton: bzr log -p -r $REVISION
[07:42] <RAOF> tjaalton: bzr alias show="log -v -p" ☺
[07:43] <jbicha> micahg: ooh, that looks useful
[07:43] <jbicha> let's just convert the CD to xz so that we can get it <700MB again ;-)
[07:44] <tjaalton> RAOF: did you mean 'bzr alias show="log -p -r"' :)
[07:44] <tjaalton> thanks anyway
[07:44] <RAOF> tjaalton: Hm, that might be a nice optimisation! :)
[07:47] <micahg> pitti: regarding Firefox 6 for maverick, I'm running a little behind, so I'll get it up later today and it'll be ready over the weekend (takes ~17hrs on armel), I can send you an e-mail before my EOD today and let you know the status and when it'll be ready to be copied to -proposed
[07:47] <pitti> micahg: cool, thanks
[08:02] <ev> pitti: looking over all of this now
[08:02] <pitti> ev: this is all post-beta 1 matter now anyway
[08:03] <pitti> ev: the main thing that concerns me is that the xklavier stuff caused hangs with the current pygobject for me, i. e. I'm afraid it might cause trouble with the current CDs
[08:03] <ev> indeed, that is worrisome
[08:04] <pitti> ev: but either it's happening in a thread, or the different program context prevents the hang
[08:04] <pitti> it doesn't seem to happen in ubiquity, just in the standalone python test case
[08:05] <pitti> doko: present for you: libdbi-drivers_0.8.3-1-0ubuntu5_source.changes just uploaded, dropping sqlite
[08:05] <pitti> doko: once that gets accepted, we can demote sqlite
[08:08] <tjaalton> hmm, does anyone know how a package depending on ia32-libs should be fixed to be installable in both oneiric and earlier releases?
[08:09] <doko> pitti, except for the php5 build failure on amd64 :-/
[08:10] <pitti> ah, right -- always the n+1st thing :/
[08:10] <doko> but hey, it's now away on powerpc and i386
[08:11] <tjaalton> ah, I'll see how flashplugin-installer is packaged
[08:13] <RAOF> tjaalton: I'm not sure that's a wonderful role-model; I believe slangasek has made dark and secretive pacts with apt to make that work.
[08:15] <tjaalton> RAOF: damn, I noticed that bibble5 wants to deinstall along with ia32-libs, and began filing a bug upstream..
[08:15] <tjaalton> and flashplugin-nonfree doesn't seem backportable anyway
[08:16] <RAOF> No, I don't think it is.  Doesn't it now Depend: on a package that's only available on i386?
[08:16] <tjaalton> which one?
[08:18] <RAOF> I can't recall.
[08:18] <tjaalton> oh I see
[08:19] <tjaalton> it has flashplugin-downloader which is i386 only, and flashplugin-installer installs it
[08:19] <tjaalton> depends on it
[08:20] <slangasek> RAOF: naw, the pact is still caught up in legal review on apt's side; mdeslaur went with a much simpler approach that doesn't involve nearly so much blood :)
[08:22] <tjaalton> slangasek: long story short; is there a way for proprietary software vendors to change the deps so that the package is installable on both multiarch and pre-multiarch ubuntu?
[08:22] <tjaalton> something like '$i386-package | ia32-libs' ?
[08:22] <tjaalton> in deps
[08:22] <tjaalton> hmm no
[08:22] <slangasek> tjaalton: they should just provide an i386 package, and people should install that via multiarch
[08:23] <slangasek> if they want to provide an amd64 package for older releases that depends on ia32-libs, they can
[08:23] <tjaalton> slangasek: ah, of course. and that exists :)
[08:23] <slangasek> (and ia32-libs isn't quite dead yet)
[08:24] <tjaalton> something is making ia32-libs deinstall on my machine
[08:24] <slangasek> that's the libv4l bug
[08:24] <dholbach> tjaalton, is it https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/808064?
[08:24] <dholbach> see the last comment
[08:25] <tjaalton> yeah, it's the same. thanks
[08:25] <slangasek> I intend to fix that tomorrow; I wouldn't trouble yourselves with having to touch ia32-libs, unless you're really keen
[08:26] <tjaalton> nah it's fine, I can reinstall bibble later, need the upgrade more
[08:26] <dholbach> I tried installing the i386 version of google-talkplugin but for some reason that didn't work
[08:27] <tjaalton> actually I'll just install the i386 version of bibble, duh
[08:28] <slangasek> dholbach: we're well short of 100% archive coverage for multiarch libraries.  Pastebin the error?
[08:31] <dholbach> slangasek, LoadPlugin: failed to initialize shared library /opt/google/talkplugin/libnpgtpo3dautoplugin.so [/opt/google/talkplugin/libnpgtpo3dautoplugin.so: wrong ELF class: ELFCLASS32]
[08:31] <dholbach> LoadPlugin: failed to initialize shared library /opt/google/talkplugin/libnpgoogletalk.so [/opt/google/talkplugin/libnpgoogletalk.so: wrong ELF class: ELFCLASS32]
[08:31] <tjaalton> bibble5:i386 installs and runs fine
[08:31] <dholbach> at least I guess that's what the problem is :)
[08:31] <slangasek> dholbach: oh.  What is that supposed to be loaded into?  Is this a browser plugin?
[08:31] <dholbach> the package installs fine and everything
[08:31] <dholbach> slangasek, yes, it is
[08:32] <slangasek> dholbach: right; ideally we'd want it integrated with nspluginwrapper then, the same way that flashplugin-nonfree is.  Who provides this package?
[08:32] <slangasek> I guess it's distributed by google directly?
[08:32] <dholbach> slangasek, Google
[08:32] <dholbach> deb http://dl.google.com/linux/talkplugin/deb/ stable main
[08:37] <slangasek> heh, their 64-bit package is made for Debian, it depends on ia32-libs-gtk which isn't in Ubunut
[08:37] <slangasek> s/ut/tu/
[08:37] <chrisccoulson> urgh, not more stuff using nspluginwrapper ;)
[08:37] <chrisccoulson> what we want is a multiarch aware plugin-container for firefox :)
[08:38] <slangasek> dholbach: so it looks like the amd64 package they provide contains a 64-bit browser plugin, plus some other 32-bit binaries for some reason
[08:39] <slangasek> that makes it tricky to do anything with on the Ubuntu side; it really would need to have the package split in two to allow for multiarch install
[08:39] <dholbach> thank god our ia32-libs provides: ia32-libs-gtk :)
[08:40] <slangasek> oh, does it?  ok
[08:40] <dholbach> that's why the package was installable at all
[08:40] <slangasek> but since they also offer a click-to-download website, they may not want to split the package in two and make it harder for users to install
[08:45] <dholbach> I'm probably missing the obvious, but wouldn't 1) removing lib32v4l-0 from ia32-libs's list of depends and 2) adding libv4l to ia32-libs solve the problem for now? (however ugly the upstream google packaging might be)
[08:45] <dholbach> ... since lib32v4l-0 is not available any more
[08:45] <slangasek> dholbach: yes, it will
[08:45] <slangasek> and that's what I'll do in the morning
[08:45] <dholbach> ok
[08:45] <dholbach> you rock!
[08:45] <dholbach> thanks
[08:46] <slangasek> but, I'd rather like it if the google upstream packaging were improved *as well* :)
[08:47] <dholbach> understood :)
[08:50] <dholbach> from what I can see http://www.google.com/intl/en/+/learnmore/forum/ is the feedback mechanism there
[09:14] <siretart> cjwatson: is it okay if I upload libav (with the MAP_ANONYMOUS bugfix of yours included) to oneiric now, despite the freeze currently being in effect?
[09:15] <pitti> siretart: sounds fine, please upload
[09:15] <pitti> we can review it from the queue, and if it seems unintrusive enough, accept it; otherwise, keep it for post beta 1
[09:17] <siretart> pitti: thanks, uploaded
[09:24] <OdyX> tkamppeter: could you please detail https://launchpad.net/ubuntu/+source/foomatic-filters/4.0.9-1ubuntu2 to me ?
[09:26] <cjwatson> astraljava: you can also (undocumentedly, sorry) pass multiple seed source URLs to -S, separated by commas
[09:33] <cjwatson> ricotz,OdyX: maverick and natty support data.tar.xz, but (in practice) not older - LP enforces that data.tar.xz uploads must Pre-Depends: dpkg (>= 1.15.6)
[09:33] <cjwatson> siretart: yep, what pitti said
[09:33] <OdyX> cjwatson: okay. Is there such an enforcement on the Debian side ?
[09:34] <cjwatson> I would have to check, but it's traditional to do that
[09:34]  * cjwatson git pulls dak
[09:34] <Sweetshark> pitti: testbuild is running again
[09:34]  * pitti tosses in some hamster food
[09:35] <ricotz> cjwatson, i am using xz tarballs for lucid+ ppas
[09:35] <OdyX> ricotz: in data.tar.gz ?
[09:35] <ricotz> OdyX, yes
[09:36] <ricotz> i.e. https://edge.launchpad.net/~wfg/+archive/0ad.dev/+packages
[09:36] <ricotz> but with lzma deb compression
[09:37] <cjwatson> ricotz: lzma != xz
[09:37] <ricotz> cjwatson, i know
[09:37] <cjwatson> lzma only requires dpkg (>= 1.14.0)
[09:38] <cjwatson> xz was not supported in dpkg until 1.15.6
[09:38] <OdyX> hmm. I think I'll drop the xz-handling for those backporting PPAs.
[09:38] <ricotz> cjwatson, like i wrote xz-tarballs which generate lzma compressed debs ;)
[09:38] <cjwatson> ok, this isn't relevant to the question
[09:39] <cjwatson> OdyX: dak doesn't seem to have the same check (IMO unwisely)
[09:39] <OdyX> cjwatson: ack. lintian either.
[09:39] <DktrKranz> OdyX: in theory, dak won't reject an upload if you don't pre-depend on dpkg, it does if the host running dak has an older version
[09:39] <cjwatson> the approach of checking Pre-Depends is borrowed from how dak used to add such features, modelled on when data.tar.bz2 was introduced
[09:41] <DktrKranz> cjwatson: perhaps that could be handled via a lintian tag + hard autoreject
[09:42] <OdyX> DktrKranz: that'd be cool, yes. But dak should run those autorejects on binary-only uploads from buildds.
[09:42] <OdyX> .oO(We should move the discussion to #debian-ftp @ OFTC.)
[09:58] <tkamppeter> OdyX, due to improvements in Ghostscript's PDF iunterpreter and PostScript output device, especially in terms of color management and speed I have switched the PDF->PS tasks from Poppler to Ghostscript in Ubuntu. To make it all consistent, I also wnted to change the built-in PDF->PS of foomatic-rip to Ghostscript, which I have done with this patch to ghet it into Ubuntu before Beta freeze. This is not a long-term solution (therefore the
[09:58] <tkamppeter>  patch instead of applying it upstream). Upstream this should be made configurable via the config file. If there is no urgency for an update of foomatic-filters in Debian, you could evcen wait for the upstream solution.
[09:58] <OdyX> tkamppeter: okay. Thank you.
[10:26] <astraljava> cjwatson: Alright, thanks! May I also ask for seeds upload again? I don't know where to check for if it's happened, I asked Luke a while back, but he hasn't replied.
[10:28] <pitti> tjaalton: do you have some insight into bug 820370? it looks a little weird
[10:31] <lenios> does anybody knows if the patch provided in https://bugs.launchpad.net/lightdm/+bug/602505 can be applied before oneiric release? https://bugs.launchpad.net/lightdm/+bug/602505
[10:31] <seb128> janimo, thanks for the unity bug fix, don't upload though please
[10:33] <pitti> jibel: https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-xorg-stakeholders-request has "[jibel] Arrange community testing for Alpha-2: INPROGRESS" -> did that happen?
[10:34] <janimo> seb128, I am not uploading, sure
[10:34] <seb128> janimo, I will likely do an upload a bit later with some other fixes included
[10:34] <seb128> janimo, thanks
[10:34] <cjwatson> astraljava: you mean an ubuntustudio-meta upload?  I did that yesterday.  Have the seeds changed since then?
[10:34] <janimo> I am not in a hurry, and let frequently uploaded packages dealt by their de-facto maintainers
[10:35] <cjwatson> astraljava: https://launchpad.net/ubuntu/+source/ubuntustudio-meta
[10:35] <cjwatson> seb128: while you're there, I don't suppose you could deal with the occurrences of unity in http://people.canonical.com/~ubuntu-archive/nbs.html ?
[10:35] <cjwatson> well, occurrence.  it still build-depends on libxcb-icccm1-dev
[10:36] <cjwatson> astraljava: ah, yes, looks like you made a couple of changes.  I'll update it
[10:36] <seb128> cjwatson, I will have a look, thanks for pointing it
[10:38] <tjaalton> pitti: yeah I just had a quick look at it when I did another commit to xorg. I'll reboot this thing and look closer..
[10:39] <vista_killer> i still have this bug with the new kernel https://bugs.launchpad.net/ubuntu/+source/linux/+bug/791089 is there a kernel ubuntu team in this irc?
[10:42] <jibel> pitti, yes. I updated the status.
[10:42] <pitti> jibel: ah, merci
[11:27] <astraljava> cjwatson: Yep, it's work-in-progress, we're lagging behind a bit for this cycle. Thanks a bunch for your cooperation!
[11:40] <mdeslaur> tjaalton: flashplugin-nonfree is kind of an exception. Normally I would just have killed the amd64 binary package. But in the flash case, we need to install nspluginwrapper on amd64. For skype and other stuff, all you need to do is simply stop shipping an amd64 package.
[11:41] <doko> Sweetshark, does the lo upload only fix the one bug, or does it introduce another one? ;-P
[11:45] <tjaalton> mdeslaur: yeah, I just forgot that you can actually install the i386 version of a blob instead (of a normal app) :)
[11:45] <tjaalton> so didn't need f-n as an example afterall
[11:45] <mdeslaur> tjaalton: cool
[11:52] <Sweetshark> doko: I work on Libreoffice, I use bigger units of measure than "1 bug"
[11:53] <Sweetshark> (unless fixing, which is always measure in "1 bug")
[11:55] <doko> Sweetshark, so can we kill the current build on armel? already ab-used some build time
[11:56] <Sweetshark> doko: the 3.4.2-2ubuntu1 build? yes
[11:59] <doko> Sweetshark, well, I would appreciate having a build on armel before beta1
[12:04] <Sweetshark> doko: 3.4.2-2ubuntu2 is already sponsored
[12:05] <doko> directhex, Laney: could you have a look at the nunit test rebuild failure? https://launchpad.net/ubuntu/+archive/test-rebuild-20110816/+build/2706515
[12:10] <mdeslaur> @pilot in
[12:16] <jtaylor> mdeslaur: can you have a look at bug 455461, thx
[12:16] <mdeslaur> jtaylor: sure, one sec
[12:17] <mdeslaur> lol...libmusicbrainz4 is _older_ than libmusicbrainz3? :)
[12:17] <jtaylor> yes, in one its weird
[12:18] <jtaylor> someone did not adher to proper library package naming
[12:18] <jtaylor> the 3 in the latter is the upstream version number no soversion
[12:19] <jtaylor> in response to a question cnd asked in the merge proposal, the extra build deps are required for building with version 3, they are also in maverick+
[12:20] <mdeslaur> jtaylor: yeah, looks fine. I'll update the bug and upload. thanks
[12:25] <jtaylor> thx
[12:28] <Laney> doko: it is fixed, ajmitch was supposed to close the bug
[12:29] <doko> Laney, thanks for the update
[12:29] <doko> Laney, was the fix in another package?
[12:35] <Laney> doko: yeah, in mono
[12:35] <Laney> the change in 2.10.4-3 fixed it
[12:42] <doko> Daviey, what is the state of bug 795087?
[12:45] <Daviey> doko: zul is away today, i'll do it shortly.
[12:46]  * apw is trying to update-manager to oneiric from natty, and i am getting some 403 Forbidden returns, known?
[12:47] <doko> Daviey, never mind, everything was done, but the state was still on incomplete, and directhex didn't see either
[12:48] <Daviey> doko: Ah, ScottK tackled it
[12:48] <Daviey> super
[12:49] <directhex> doko, in upstream 2.10.4, upstream reverted a detail we were relying on for our transition to work. we reverted their revert in 2.10.4-3.
[12:50] <cjwatson> apw: any chance of switching lbm over to 3.0.0-9?
[12:51] <apw> cjwatson, can do
[12:52]  * cjwatson is unaware of 403 Forbidden on upgrade; no doubt it depends on the mirror
[12:52] <cjwatson> gb.archive seems kind of outdated the other day
[12:52] <cjwatson> *seemed
[12:53] <Daviey> cjwatson: i noticed i was getting 403's via squid-deb-proxy the other day, with that disabled it worked.
[12:59] <apw> cjwatson, yeah seems that the files are there but not readable on gb.a.u.c ok on a.u.c
[13:00] <apw> cjwatson, who owns talking to mirrors about problems
[13:02] <cjwatson> apw: not sure, try #ubuntu-mirrors
[13:05] <ScottK> Daviey: What did I tackle?
[13:11] <Daviey> ScottK: lots, and lots of win.
[13:12] <Daviey> ScottK: you fixed python-netifaces
[13:12] <ScottK> Oh, right.  The broken dh_python2 transition.
[13:12] <ScottK> No problem.
[13:12] <Daviey> yah
[13:12] <Daviey> thanks.
[13:31] <apw> cjwatson, just checking you want this -lbm update for oneiric uploaded now?
[13:34] <cjwatson> apw: yes please, if you can
[13:35] <apw> cjwatson, on it
[14:14]  * apw is just doing an upgrade and gdm and not lightdm is the default in the popup dialog, is that expected or a bug
[14:15]  * Sweetshark is happy about his big ceiling fan today.
[14:30] <victorp> sconklin, ping
[14:30] <sconklin> victorp, what's up?
[14:31] <victorp> sconklin, I have a quick questoin
[14:31] <victorp> question rather
[14:31] <victorp> about srus and security patches
[14:31] <victorp> do we have a kernel that only updates with security updates or the -updates kernel is the only one for maintenance
[14:31]  * victorp not sure that question made any sense
[14:32] <jdstrand> I can answer that
[14:32] <victorp> jdstrand, cool
[14:32] <victorp> fwiw I am mainly interested for server
[14:32] <jdstrand> victorp: in almost all cases, kernels with security fixes will have srus fixes as well. that is the SRU cadence
[14:33] <victorp> right
[14:33] <jdstrand> victorp: if an -updates kernel has no security fixes, it doesn't go to -security
[14:33] <pgraner> victorp, to answer you question the is not just a security stream
[14:33] <victorp> pgraner, yes - that was my question
[14:34] <jdstrand> victorp: it is theoretically possible for an out of band kernel to go through -security only, with no sru patches, but this is only for emergencies
[14:34] <victorp> so -security is not only security fixes, but all security fixes + whatever else made it into that kernel
[14:34] <victorp> jdstrand, ack
[14:35] <jdstrand> victorp: well, -security is for kernels with security fixes-- and they typically have other things as well
[14:35] <victorp> yes, makes sense
[14:35] <jdstrand> victorp: it used to be a bit different, but that was untenable and why we have the current process
[14:35] <jdstrand> (now)
[14:36] <victorp> the reason I am asking is because I need to figure out how often we need to test somethink that has a dependecy on ABI
[14:36] <victorp> so I was hoping that -security would break ABI less often that -updates
[14:37] <jdstrand> victorp: you might lighten your kernel churn by disabling -updates, but the frequency of vulns found in the kernel kinda makes it unlikely that it would be significantly fewer upgrades
[14:37] <victorp> but sounds that it would be almost as often
[14:37] <victorp> jdstrand, agreed
[14:38] <victorp> sconklin, I am right on assuming that each new -updates kernel is very likely to break ABI compatibility with the previous one?
[14:39] <pgraner> victorp, yes, it almost always does
[14:40] <victorp> pgraner, thanks that is what I though. fair enough
[14:40] <om26er> mdeslaur, Hi! could you sponsor https://code.launchpad.net/~om26er/ubuntu/oneiric/empathy/fix-crashes/+merge/72761 please
[14:40] <mdeslaur> om26er: let me take a look
[14:49] <om26er> mdeslaur, are you bulding it?
[14:49] <mdeslaur> om26er: I will, yes...but am asking in #ubuntu-release if I can upload it since the archive is frozen
[14:52] <om26er> ok.
[14:56] <mdeslaur> om26er: ok, got approval, will upload in a few minutes
[14:58] <om26er> mdeslaur, great, thank you :)
[15:25] <pitti> ogasawara: OOI, why are the 3.0.1 upstream kernels called 3.0.0-9?
[15:29] <ogasawara> pitti: mostly old habits... when we'd originally had 2.6 kenels we stayed with the 2.6 package version, even though they were technically 2.6.x.  And we originally started out with a 2 digit 3.0 version scheme.  Now that we're into a 3 digit scheme, we could likely start reflecting the actual stable version.
[15:29] <ogasawara> pitti: I'll bring it up with the rest of the team
[15:30] <pitti> not a biggie, I just wondered
[15:33] <ogasawara> pitti: tgardner did also bring up a good point that we don't always take all of upstream stable, so it wouldn't be entirely accurate
[15:36] <ogra_> pitti, seems tp-glib is gone from http://qa.ubuntuwire.org/ftbfs/ too now, seems it got fixed today
[16:02] <mdeslaur> @pilot out
[16:05] <cjwatson> ScottK,debfx: would anyone cry if I dropped the ruby-kate package?  it can't build since kate_smoke went away
[16:05] <ScottK> cjwatson: No.  Removing it is on the TODO list.
[16:06] <cjwatson> I'll go ahead and do that then
[16:06] <ScottK> Hopefully the qtruby upload that debfx did will make korundum buildable so I can do that.
[16:09] <pitti> cjwatson: anythign I can help with there in ubuntu-defaults-image?
[16:10] <cjwatson> ScottK: no, not quite, that's where I was starting from
[16:11] <cjwatson> ScottK: but the thing that breaks is the include of kate_smoke.h - it's not testing for that properely
[16:11] <cjwatson> so I wanted to know whether the obvious "check that and don't build the kate module" was right
[16:11] <ScottK> Yes.  Please.
[16:11] <cjwatson> pitti: u-d-i is OK I think, it's something wrong with the livecd-rootfs integration
[16:12] <cjwatson> the log didn't have anything obvious
[16:12] <pitti> next week I'll look at making the iso smaller, it currently comes out at 740 MB or so
[16:16] <tjaalton> pitti: sorry, couldn't fix that xorg bug, spent too much time triaging unity ;) but next week
[16:16] <pitti> tjaalton: oh, I just wondered if this is "triaged", or needs some further debugging/explanatino
[16:17] <pitti> tjaalton: the half of it where it doesn't remove a non-empty directory isn't a bug, but there was some other half which did sound like a breakage; I just wondered why /etc/gdm is covered by the generic x11-common package
[16:19] <pitti> have a nice weekend everyone!
[16:21] <tjaalton> pitti: because failsafe-x used to install stuff there, and kubuntu system doesn't have gdm
[16:24] <cjwatson> ScottK: does http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/korundum/revision/6 look plausible to you?
[16:25] <cjwatson> oh, I should add DEP-3 headers
[16:26] <cjwatson> (done)
[16:33] <ScottK> cjwatson: Yes.
[16:34] <cjwatson> ok, uploading, thansk
[16:34] <cjwatson> *thanks
[16:37] <ScottK> cjwatson: Accepted.
[17:01] <bdmurray> Is there a patch piloting schedule so I can figure out who to wait for and pounce on?
[17:05] <stgraber> bdmurray: IIRC there's a google calendar for that
[17:06] <micahg> bdmurray: it's rodrigo and mdeslaur today, my guess would be both are done for the day
[17:06] <bdmurray> :-(
[17:06] <mdeslaur> bdmurray: I'm done, but do you want me to look at something?
[17:06] <stgraber> bdmurray: Calendar ID<EMAIL_ADDRESS>[17:07] <stgraber> bdmurray: I'm also happy to sponsor
[17:07] <bdmurray> Thanks - https://code.launchpad.net/~brian-murray/ubuntu/oneiric/apport/ubiquity-dupe-sig/+merge/72989
[17:08] <stgraber> looking
[17:08] <bdmurray> I've detailed what this does in the merge proposal and I could provide more information about the testing I've done if somebody wants to test it.
[17:09] <stgraber> bdmurray: is that something you'd like to have for beta1? (I'll upload anyway but you may want to poke -release if you want it in for beta1)
[17:09] <bdmurray> stgraber: yes so we can get the duplicate signature in the bugs as people are testing
[17:09] <bdmurray> stgraber: this allows the retracer to automatically duplicate bug reports
[17:10] <stgraber> bdmurray: ok, I'll review, upload and mention it in -release then
[17:11] <bdmurray> stgraber: great, thank you!
[17:22] <apw> cjwatson, i tried to upload the oneiric-lbm you requested, but just noticed it got bounced as linux-backports-modules-3.0.0 is not on the kernel upload rights
[17:31] <kees> how do I make network-manager not steal my resolv.conf ?
[17:32] <infinity> kees: chattr +i? :P
[17:32] <infinity> kees: (Or stop managing interfaces with NM...)
[17:32] <nigelb> infinity: hehe, that's what I'd done.
[17:33] <infinity> kees: I dunno.  I just use append/prepend/supersede in dhclient.conf to get a nice merge of "what the DHCP server told me" and "what I actually want".
[17:33] <mdeslaur> kees: click on the options, and select "automatic dhcp, adresses only"
[17:33] <infinity> kees: Which seems to me like the "correct" solution, cause you do kinda want to know what the DHCP server told you too, right?
[17:34] <kees> well, see, the problem is I have none of my interfaces managed by network-manager, but it decides to wipe out resolv.conf anyway
[17:34] <infinity> kees: Err, oh.  That's differently special.
[17:34] <mdeslaur> kees: you wireless either?
[17:34] <kees> this is on my desktop.
[17:34] <mdeslaur> kees: what you need to do is have network manager manage ALL your interfaces...then it just works :)
[17:35] <kees> or maybe there's some magic interface it thinks its managing? how do I get it to tell me which it's operating on?
[17:35] <kees> mdeslaur: no, no, that's the opposite of what I want. :)
[17:35] <mdeslaur> kees: that's cause you're doing it wrong :)
[17:35] <mdeslaur> kees: does it have an auto interface listed in "wired connections"?
[17:36] <kees> mdeslaur: it's not wrong -- it's a server as far as I'm concerned. :)
[17:36] <mdeslaur> kees: why are you running network manager on a server?
[17:36] <infinity> And why does a server have NM installed?
[17:36] <mdeslaur> lol
[17:36] <mdeslaur> attack of the trolls
[17:36] <kees> this circular trolling isn't working
[17:36] <infinity> We can try harder!
[17:36] <kees> hehe
[17:36] <infinity> But yeah, does NM list any interfaces in the drop-down UI?
[17:36] <kees> okay, so, if I start nm, it wipes out my resolv.conf.
[17:36] <mdeslaur> kees: seriously, do you have an auto interface in "Wired"?
[17:37] <kees> mdeslaur: I don't have an applet because it's not running
[17:37] <infinity> You're the best debugging buddy ever.
[17:37] <kees> sudo chattr +i /etc/resolv.conf; sudo service network-manager start ...
[17:37] <infinity> "My car's making weird noises, but I left it at home."
[17:38] <mdeslaur> kees: either kill it completely, or don't kill it at all
[17:38] <mdeslaur> kees: in /etc/NetworkManager/system-connections, do you have any files?
[17:38] <kees> nope
[17:39] <kees> mdeslaur: okay, in the applet, "enable networking" is greyed out :)
[17:39] <kees> well let me chattr -i again, just for fun
[17:40] <kees> currently, the file is fine. nm loves to gas-light me
[17:40] <kees> uhp, nope, there is goes. wiped the file.
[17:41] <kees> mdeslaur: okay, I have no network connections listed in the "edit connections" dialog.
[17:41] <mdeslaur> hmm
[17:41] <kees> and yet it wiped out the file.
[17:41] <mdeslaur> that's not very nice
[17:41] <kees> agreeds
[17:41] <mdeslaur> open a bug
[17:41] <kees> will do.
[17:41] <kees> in the meantime.... chattr +i :)
[18:41] <lucidfox> YokoZar, any chance for a wine1.3 update in Oneiric?
[18:57] <nigelb> 32-bit binaries should work fine on 64-bit machines, shouldn't they?
[18:58] <lucidfox> if the required libraries are installed, yes
[18:59] <nigelb> Mine just fails. Sigh.
[18:59] <ion> and if the architecture supports 32-bit code.
[18:59] <nigelb> x86_64
[18:59] <nigelb> The longer fix is to just use 64-bit, but I'm puzzled by the failure.
[19:03] <infinity> nigelb: How does it fail?
[19:04] <nigelb> infinity: well, it just doesn't work. I tried with 64-bit binary and it worked. I canste the error if you'd like.
[19:04] <infinity> An error tends to be more informative than "doesn't work". ;)
[19:05] <nigelb> "-bash: ./check_disk: No such file or directory"
[19:05] <slangasek> that would be the classic posix error value, ENOWORKIE
[19:05] <infinity> But it's probably as lucidfox says, and you're missing some 32-bit userspace bits.
[19:05] <slangasek> nigelb: you don't have the 32-bit ld.so.
[19:05] <nigelb> ah.
[19:05] <nigelb> how do I get them?
[19:05] <slangasek> you need to install the libc6:i386 package (or on pre-oneiric, libc6-i386)
[19:05] <nigelb> wait, this is lucid.
[19:06] <infinity> Yeah, libc6-i386 on lucid.
[19:06] <nigelb> ah.
[19:06] <nigelb> I should have read, appologies.
[19:06] <nigelb> hm, when did this locale error start showing up :|
[19:07] <infinity> Perl complaining about your locales?
[19:07] <nigelb> yeah
[19:07] <infinity> That's entirely valid. :P
[19:07] <nigelb> I need to note down somewhere how I fix it.
[19:07] <infinity> The machine you're SSHed into doesn't have the locale generated that your client pushed.
[19:08] <nigelb> so, its not a server thing, but just something a combination of that machine + client?
[19:08] <infinity> (ie: if you are SSHing from a machine with en_US.UTF-8, it will helpfully push that to the remote machine, which doesn't have it built)
[19:08] <nigelb> ah, I know what's wrong then.
[19:08] <infinity> It's not a "problem" with either machine, per se, except that I consider remote locale poisoning a braindead feature.
[19:08] <nigelb> I'm SSH-ing into a server from another server.
[19:09] <infinity> But then again, I speak English.  I imagine others find the feature pretty handy.
[19:09] <nigelb> Phew, I was afraid of another few hours of debugging.
[19:09] <nigelb> I doubt my terminal has had to display anothing non-English.
[19:09] <nigelb> well, except when I'm using irssi.
[19:10] <mdeslaur> infinity: yeah, but you get weird spelling when the remote machine doesn't have en_CA
[19:10] <infinity> But yeah, the messages are harmless, and only due to your LANG being set to a locale that the host doesn't have installed/built.
[19:10] <infinity> Everything gracefully falls back to LANG=C in that case anyway.
[19:10] <nigelb> "gracefully"?
[19:10] <nigelb> :)
[19:10] <infinity> Well, perl's verbose about it.
[19:11] <infinity> But it still works!
[19:11] <nigelb> except autocompletion throws me 3 lins of errors
[19:11] <nigelb> ;)
[19:11] <infinity> That's marginally more icky, yes.
[19:11] <infinity> Fix your locales? :P
[19:12] <nigelb> My usual fix is to do export LC_ALL="en_US.UTF8" in the .bashrc
[19:12] <nigelb> is that a kosher enough fix? :)
[19:12] <infinity> If only that was a valid locale...
[19:12] <nigelb> oh.
[19:12] <infinity> Plus, you probably want LANG, not LC_ALL.
[19:13] <infinity> But more importantly, I'm assuming that server you're on doesn't have any locales generated.
[19:13] <infinity> Which is pretty common.
[19:13] <nigelb> what is the Right thing to do™?
[19:13] <nigelb> generate locales?
[19:13] <infinity> If you want UTF all over and the same locale all over, just "sudo locale-gen en_US.UTF-8" on all your hosts.
[19:13] <nigelb> localegen or some such?
[19:13] <infinity> Or install a langpack.
[19:14] <infinity> Which will do it for you.
[19:14] <infinity> SSH will helpfully forward your LANG across connections, so if your local locale also exists on the target host, it all Just Works.
[19:14] <nigelb> aha, thanks!
[19:15]  * nigelb removes the .bashrc hack
[19:17] <nigelb> infinity: I owe you a beer! :D
[19:42] <cjwatson> apw: you should have linux-backports-modules-3.0.0 upload rights now
[20:45] <jdstrand> apachelogger: hey, is there a bug associated with your kde-l10n-ug upload?
[20:52] <jdstrand> apachelogger: actually, I had another question. sent via email
[22:23] <jo-erlend> how do I report a security issue that causes you to gain access to a locked desktop by pressing a keyboard combination? I don't know what package to file against, and launchpad won't let me file bugs without associating with a package.
[22:24] <ion> Report it against gnome-screensaver, the most probable culprit. If it’s not a gnome-screensaver issue, someone will change it.
[22:24] <jo-erlend> oh, ok.
[22:47] <bdmurray> Has anybody run into this issue when authenticating with Launchpad via launchpadlib?
[22:48] <bdmurray> ERROR: connecting to Launchpad failed: unclosed token: line 38953, column 8
[22:58] <bdmurray> Well okay the last thing I did that may have resolved it was rm * in ~/.launchpadlib/api.launchpad.net/cache


[01:43] <lamont> cprov-out: https://edge.launchpad.net/ubuntu/+source/vlc/0.8.6.release.c-0ubuntu5
[01:43] <lamont> le huh??
[01:46] <stdin> wow, so good they built it twice
[01:47] <Odd_Bloke> s/good/nice/
[03:28] <cprov-out> lamont: don't worry, it's one of the victims of the 'duplicated-build-disaster'. It will get fixed after gutsy release.
[03:28] <lamont> ok
[03:32] <lamont> only 4022 build records to clear, and about a week to do it... hrm.
[05:16] <lamont> as in I keep seeing it building
[05:16] <lamont> and then it's building again later
[05:25] <lamont> and claiming that primero and kohnen are building it (or some such..)
[10:26] <bersace> Hi all
[10:26] <bersace> How to fix a "Fail to upload" error ?
[10:26] <bersace> ah ok
[10:26] <bersace> i found the bug
[01:05] <iwj> Would some Malone or Soyuz developer care to take a quick look at bug 151925 and (i) set the status of the Launchpad task appropriately and (ii) answer my question at the bottom about the delay interval for my workaround ?
[01:05] <ubotu> Launchpad bug 151925 in autopkgtest "Bugs set to Fix Released by changelog-closes-bugs before fixed version is published" [Medium,Confirmed]  https://launchpad.net/bugs/151925 - Assigned to Ian Jackson (ijackson)
[01:10] <ubotu> New bug: #151925 in autopkgtest "Bugs set to Fix Released by changelog-closes-bugs before fixed version is published" [Medium,Confirmed]  https://launchpad.net/bugs/151925
[01:24] <bigjools> iwj: stuff generally gets published every hour, so that's a good starting point
[01:24] <iwj> bigjools: OK, well, I'll call it 2 or 3h then.
[01:25] <bigjools> iwj: ok :)
[01:26] <iwj> Note that this number has to include build time too.
[01:28] <bigjools> indeed
[01:48] <AnMaster> how do you do the bzr+ssh thing so only bzr+ssh but not for example ssh and starting bash works?
[01:48] <mwhudson> AnMaster: custom ssh daemon
[01:48] <AnMaster> mwhudson, ah, non open source?
[01:48] <AnMaster> I was trying to run some commands like /bin/bash --norc with it
[01:49] <mwhudson> AnMaster: well it's based on twisted.conch
[01:49] <mwhudson> the parts that aren't conch aren't amazingly exciting
[01:49] <AnMaster> so sshd in python
[01:49] <AnMaster> interesting
[01:50] <AnMaster> mwhudson, I'm still interesting in seeing how it works :)
[01:50] <AnMaster> I would need something like that for another restricted service myself (though not bzr in this case)
[01:57] <mwhudson> AnMaster: it's really pretty simple
[01:57] <mwhudson> conch's ISession interface has an execCommand method
[01:57] <AnMaster> mwhudson, if you are good at python: I bet
[01:57] <mwhudson> look at what you get asked to execute
[01:57] <mwhudson> either execute it, or don't
[01:57] <AnMaster> I'm not good at python (though I'm good at some other languages)
[01:58] <AnMaster> hm interesting
[01:58] <AnMaster> mwhudson, but why do ssh<EMAIL_ADDRESS>"/bin/bash --norc" cause so odd results?
[01:58] <AnMaster> that is you are dropped to something that seem like cat - > /dev/null
[01:59] <mwhudson> i don't know
[02:02] <spiv> That'd be a bug.  It ought to be rejecting the request to exec that command (or perhaps just closing the channel?).
[02:03] <AnMaster> spiv, well try it and see what I mean
[02:03] <spiv> I did.
[02:03] <AnMaster> it doesn't run the command but it does something odd
[02:07] <spiv> Right, that server will not run arbitrary commands for you.
[02:08] <spiv> The bug is that it doesn't refuse them clearly; the client just thinks nothing's happening.  The server ought to be explicitly rejecting the "please run this command" request.
[02:09] <spiv> I think there may already be a bug on launchpad-bazaar about this.  (If not, there should be.)
[02:10] <AnMaster> well I won't search and report, I got some other things to do atm
[02:20] <ubotu> New bug: #151950 in launchpad-bazaar "the branch listings should be searchable" [Undecided,New]  https://launchpad.net/bugs/151950
[03:01] <stgraber> Any LP admin around with some time to rename ubuntu-qa-tracker to ubuntu-qa-website ?
[03:09] <mrevell> stgraber: Hi
[03:09] <stgraber> hi mrevell
[03:10] <mrevell> stgraber: The best way to request that is to file a support request at: https://answers.launchpad.net/launchpad
[03:10] <mrevell> stgraber: I'd happily do it for you but if you file it you'll get the response from Tom when he sorts it.
[03:10] <mrevell> yo Hobbsee
[03:11] <stgraber> mrevell: ok, I'll do that
[03:11] <mrevell> stgraber: thanks
[04:05] <shriphani> doesn't launchpad host projects? like providing repos etc ?
[04:40] <iwj> I'm getting repeated timeouts trying to file a bug against firefox.
[04:40] <iwj> https://edge.launchpad.net/ubuntu/+source/firefox/+filebug
[04:40] <iwj> and I type "irc URL doesn't work" into the box.
[04:40] <iwj> OOPS-650EC90 for example.
[04:41] <iwj> Aha, it seems to have worked.  I wonder if it will let me submit it.
[04:46] <popey> mrevell: what's the process when a launchpad user is spamming the wiki?
[04:46] <mrevell> popey: which wiki?
[04:46] <popey> w.u.c
[04:46] <mrevell> popey: Well, everyone using w.u.c is a Launchpad user :)
[04:46] <mrevell> popey: Sorry, I think I might be misunderstanding what you mean.
[04:47] <popey> ok, I'll edit your page and say you suck.. what you going to do? :)
[04:47] <mrevell> popey: hehe
[04:47] <popey> 15:05:19 < popey> https://edge.launchpad.net/~Rosebuntu seems to keep naffing up https://wiki.ubuntu.com/LoCoTeamList
[04:47] <popey> 15:05:29 < popey> repeatedly editing out other peoples names and screwing with urls
[04:47] <popey> 15:44:36 < popey> and again
[04:47] <popey> is this one for jono?
[04:47] <popey> i have reverted the change twice, and others have reverted rosebuntus change also
[04:48] <mrevell> popey: It depends how urgent it is. I can certainly speak to one of the admins and ask for a hold to put be on the account if it's urgent. However, I'd suggest Jono's probably the one to speak to as it's an Ubuntu community matter I'd say.
[04:48] <popey> ok
[04:48] <popey> will do
[04:49] <mrevell> Perhaps we should have a conversation with Jono.
[04:49] <mrevell> To make sure I also understand the Ubuntu community process
[04:49] <mrevell> I'll ping him into the channel
[04:49] <popey> ok
[04:50] <jono> hey
[04:50] <popey> moo
[04:50] <popey> jono: https://edge.launchpad.net/~Rosebuntu seems to keep naffing up https://wiki.ubuntu.com/LoCoTeamList
[04:51] <popey> i have reverted the change twice, and others have reverted rosebuntus change also
[04:51] <jono> one sec
[04:52] <jono> popey: how naffing up?
[04:53] <popey> changing urls to the korean wiki and korean loco team home page
[04:53] <popey> and sometimes changing the name of the loco contact
[04:53] <jono> popey: has someone contacted rosebuntu about this?
[04:54] <popey> i sent a mail to rosebuntu
[04:54] <popey> and they edited the page again after I sent it
[04:55] <jono> popey: right, first step is to ask he/she to stop doing it I guess
[04:55] <Hobbsee> why did i read he/she/it there?
[04:55] <popey> the drugs aren't working Hobbsee ?
[04:56] <Hobbsee> i dunno...
[04:57] <jono> Hobbsee: I think you need more sleep, chuck
[04:57] <jono> :)
[04:57] <Hobbsee> jono: mmm...maybe...
[04:57] <jono> Hobbsee: :)
[04:58] <mrevell> jono welcome to the happy Launchpad family.
[04:58] <mrevell> :)
[04:58] <jono> mrevell: :)
[05:41] <RainCT> Hi
[06:03] <RainCT> some LP guy there?
[06:08] <gmb> c!
[06:08] <gmb> RainCT: Sure, how can I help?
[06:10] <RainCT> gmb: Hi. I've noticed a while ago that you can create a branch with underscores (_) in the name on Launchpad and it will work fine, but if you try to change it's description there it won't let you, saying that it don't allows the character in the name.. I just wondered if you already know about this
[06:11] <gmb> RainCT: Ah. I think this is an issue which has cropped up recently. I'm not the person to talk to about it though. Hang on and I'll see if I can find someone who can be of more use to you :)
[06:13] <RainCT> gmb: ok, thanks. (for the caase you thing so, this is no problem for me right now, I just say it so that you know about it ;))
[06:14] <gmb> RainCT: Okay. Thanks for giving us the heads up. I think that we do know about it but that's not my area of expertise in LP, so I just wanted to be sure.
[06:16] <mwhudson> RainCT: hi
[06:16] <mwhudson> RainCT: this is bug https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/95109
[06:16] <ubotu> Launchpad bug 95109 in launchpad-bazaar "It is possible to register branches with '_' in their name" [High,Confirmed]   - Assigned to Michael Hudson (mwhudson)
[06:17] <mwhudson> it'll be fixed soon
[06:17] <mwhudson> i was going to fix it yesterday but another bug i was on took way longer than i expected to finish
[06:18] <RainCT> ok, thanks. what will the fix be? allow underscores or make it impossible to use them neither with bzr?
[06:18] <AnMaster> mwhudson, _ should be allowed IMO
[06:19] <mwhudson> AnMaster: that's a different question, in some sense
[06:20] <AnMaster> and I prefer to use same name in all places for a branch
[06:20] <mwhudson> RainCT: to ban underscores
[06:20] <AnMaster> ugh why?
[06:20] <mwhudson> RainCT: with launchpad
[06:20] <AnMaster> why do you hate underscores?
[06:20] <mwhudson> RainCT: of course you can call local branches whatever your filesystem wants to call them
[06:21] <mwhudson> AnMaster: it's harder to communicate
[06:21] <mwhudson> AnMaster: read the bug report
[06:21] <AnMaster> and how often do you say a branch name?
[06:21] <AnMaster> I mean often you write it
[06:21] <AnMaster> like on irc
[06:22] <mwhudson> AnMaster: i could talk to you about it, but it's 5 pm on a friday
[06:22] <mwhudson> so i'm going to go and play quake instead
[06:22] <AnMaster> mwhudson, if you want that, I should note that saying ~ is hard too
[06:22] <AnMaster> ;P
[06:22] <radix> AnMaster: you should really read the bug report for the basic arguments :)
[06:22] <mwhudson> have a nice weekend
[06:22] <RainCT> ...they're hard to type, read out and so forth Really? I personally prefer underscores instead of -'s, the only problem with them is if the text is  understroked
[06:22] <AnMaster> radix, ~ is used in launchpad urls
[06:22] <AnMaster> yet it is hard to say
[06:22] <AnMaster> what is the name in English even? wiggly dash?
[06:22] <radix> tilde
[06:23] <mwhudson> the really really bad part of the bug is that different parts of the system disagree on what branches are called
[06:23] <RainCT> mwhudson: well, good weekend. thx
[07:25] <shriphani> can anyone assist me with picking a licence?
[08:00] <sinequanon> hi all.    Can the launchpad bug tracker be used for non-FOSS projects?  It seems that the PPA license agreement would preclude commercial projects, but the general terms of service page doesn't seem to say anything on the matter.
[08:02] <statik> sinequanon: it's not a stupid question. you can email me (elliot at canonical dot com) with the particulars of your situation and we can discuss it
[08:07] <mdke> statik: it would be interesting to hear more about that actually; the front page of LP refers to the "free software world", is there more documentation about the subject?
[08:09] <statik> mdke: not much documentation at the moment, unfortunately. it's kind of a quid pro quo thing, we are happy to provide LP for free to free software projects, but if non-free projects want to use the service then we ask to negotiate individually
[08:11] <mdke> statik: ok cool.  but if the service is available to non-foss projects, probably the word "free" should be removed from that phrase on the front page, to make it accurate, right?
[08:13] <statik> mdke: I think the description is still accurate, LP makes it easy to interact with free software projects
[08:14] <mdke> heh. As a matter of language it's accurate, yes
[08:14] <statik> mdke: but perhaps it could be improved, I haven't thought about that before
[08:15] <mdke> just dropping "free" would make it a more complete description, I think (plus it might encourage more non-foss projects). You'd need to develop a bit of documentation about how non-foss projects can contact you and so on
[08:20] <mwhudson> well, it's assumed that the non-foss projects that want to use launchpad will still interact with the foss projects i think
[08:21] <ScottK> FOSS projects might not be happy about that though.
[09:44] <FlyingPig> help me order gusty gibbon!!!!!!
[09:44] <FlyingPig> free cd
[09:44] <FlyingPig> i cant do this
[09:45] <FlyingPig> HELLO?
[09:45] <FlyingPig> HELP ME ORDER GUSTY GIBBON
[09:45] <FlyingPig> HELLO??????????????
[09:46] <synic> wow.
[09:47] <synic> FlyingPig: do you have a launchpad account?
[09:48] <FlyingPig> synic i dont think so, no
[09:48] <synic> https://shipit.ubuntu.com/login
[09:48] <FlyingPig> synic k
[09:48] <synic> apparently you need to create a launchpad account
[09:50] <FlyingPig> synic ok now i did this
[09:50] <FlyingPig> now i want order gutsy gibbon cd
[09:50] <synic> then login at that page, and you can fill out your address, etc.
[09:50] <FlyingPig> ok
[09:53] <FlyingPig> synic ok now i did this. thanks for all help sir. i will install on all computer in my house and company. maybe i will donate some money for you as thanks in future.
[09:53] <FlyingPig> synic if i use feisty fawn today and i not want to destroy all my gui settings how i get this settings on my new ubuntu without doing over all settings is there a file i can copy and paste over?
[09:53] <synic> don't donate any money to me, I had nothing to do with it.  Donate to Ubuntu :)
[09:54] <FlyingPig> yes ok
[09:54] <synic> FlyingPig: you can do it over the network.. once Gutsy is released, edit /etc/apt/sources.list and change all instances of feisty to gutsy... save it, apt-get update && apt-get -u dist-upgrade
[09:54] <synic> I dunno if you can do it via the CD... you probably can, but I don't know how.
[09:55] <Spads> synic: that's not the recommended way to upgrade
[09:55] <synic> Spads: what is?
[09:56] <FlyingPig> synic i thought the sources list only have urls for sudo apt-get install
[09:56] <FlyingPig> ???
[09:56] <Spads> http://www.ubuntu.com/getubuntu/upgrading
[09:56] <FlyingPig> spads i want have same Gnome settings in new ubuntu please
[09:56] <Spads> but this is probably a topic best kept to #ubuntu or #ubuntu+1
[09:56] <FlyingPig> what file i need to copy and paste?
[09:56] <Spads> It is not relevant to Launchpad per se.
[09:57] <Spads> FlyingPig: #ubuntu can help you out better than I can.
[09:57] <FlyingPig> spads ok thanks
[09:57] <FlyingPig> ok i order cd and it work so i am done here. thank
[10:24] <stdin> wow, someone want LP to be their friend
[10:49] <jjesse> quick question to update my local branch from launchpad i do a bzr merge correct?
[10:50] <synic> or pull, depending on if you have local changes
[10:50] <jjesse> thanks synic
[12:27] <mae^> how do I add a bug report?
[12:27] <stdin> to what?
[12:28] <mae^> a project
[12:28] <radix> go to that project's Launchpad page, and there should be a "report a bug" button on it.
[12:28] <stdin> https://bugs.launchpad.net/<PROJECT>/+filebug
[12:28] <mae^> I'm in the bugs tab and all i see is list {assigned,related} bugs, show pkg report, list subscribed bugs and mentoring offered
[12:29] <mae^> radix: when you say the project page, do you mean the overview tab?
[12:29] <radix> mae^: sure, there's one there. there's also one in the main Bugs tab page, too.
[12:29] <pochu_> mae^: look at the right, not at the left :)
[12:30] <radix> mae^: What URL are you looking at that doesn't have a Report a Bug button?
[12:30] <mae^> hmmm.. i dunno why i'm not seeing it
[12:30] <mae^> https://launchpad.net/~activerdf/
[12:30] <radix> that's a team, not a project.
[12:30] <mae^> ah!
[12:31] <radix> https://edge.launchpad.net/activerdf <-- that's probably what you want
[12:32] <mae^> thanks
[12:44] <danigm_> hi, I have a question about the log of a branch in launchpad. I have a team, and in the team there are two people, each developer has their branch, and when he push it, the log of the other developer disappear, and it's reemplaced with the new log branch.
[12:46] <danigm_> there is some method for show all changes, including the parent branch
[12:46] <danigm_> ?
[12:48] <mdke> statik: I filed the issue we discussed earlier as a bug; maybe others will have some thoughts