[00:00] <TheMuso> dtchen: ok got your changes, will pull them in and upload.
[00:00] <dtchen> TheMuso: thanks!
[00:46] <TheMuso> Hrm. Is it a known bug that one can simply eject a DVD/CD using the button on the drive, and the icon remain on the desktop?
[00:46] <TheMuso> In the past, I have had to sometimes kill processes in order to let the system eject the drive.
[06:47] <pitti> Good morning
[07:03] <didrocks> Guten Morgen pitti
[07:04] <didrocks> (6 years of German and 2 words remaining :/)
[07:04] <pitti> bonjour didrocks!
[08:01] <tkamppeter> pitti, hi
[08:03] <pitti> hey tkamppeter
[08:04] <tkamppeter> pitti, have you seen my mails?
[08:04] <pitti> tkamppeter: FYI, I uploaded a cups without fail-on-testfail last night, so that we at least get the other fixes into the archive
[08:04] <pitti> tkamppeter: just one mail, yes
[08:04] <tkamppeter> pitti, it is now about s-c-p.
[08:05] <tkamppeter> pitti, yes, it was only one.
[08:05] <pitti> tkamppeter: please just upload it, so that it's in the queue for review
[08:05] <tkamppeter> pitti, it is already.
[08:05] <pitti> ah, nice
[08:06] <tkamppeter> pitti, this hpcups is really broken and if we leave s-c-p using it by default we will get a lot of complaints of HP printer users.
[08:06] <pitti> tkamppeter: until when did it prefer the hpijs backend?
[08:08] <pitti> Amaranth: hm, that new compiz upload is pretty intrusive; the other packages around it look okay, and I accepted them (reviewing -gconf now)
[08:10] <tkamppeter> pitti, in Jaunty there was only an hpijs backend.
[08:11] <tkamppeter> pitti, I made s-c-p prefering hpcups somewhere in the middle of the Karmic cycle.
[08:11] <tkamppeter> pitti, then users started complaining but I hoped that HP could perhaps give me one or another patch.
[08:12] <pitti> tkamppeter: ok, thanks
[08:12] <tkamppeter> pitti, I made the decision to switch back to HPIJS somewhere last week and modified HPLIP appropriately, but totally forgot s-c-p.
[08:13] <pitti> Amaranth: why does compiz remove the gconf backend? this looks like a very intrusive change to me?
[08:14] <tkamppeter> pitti, thanks.
[08:21] <pitti> Amaranth: I asked in bug 439287; can you please reply in the bug, to have a record of the discussion for Steve as well?
[08:35] <chrisccoulson> good morning everyone
[08:41] <pitti> hey chrisccoulson
[08:41] <chrisccoulson> hey pitti
[08:41] <chrisccoulson> how are you?
[08:42] <pitti> pretty good, unlike the past two nights I really slept well last night
[08:42] <pitti> how about you?
[08:43] <chrisccoulson> i had quite a late night last night ;)
[08:43] <pitti> I just found I couldn't/shouldn't do that three times in a row, so I went to bed early
[08:44] <chrisccoulson> yeah, i might get an early night tonight
[08:44] <chrisccoulson> unless i can pick another RC bug to work on ;)
[08:44] <chrisccoulson> then it might end up being a late night again!
[08:45] <chrisccoulson> but at least it is saturday tomorrow ;)
[08:47] <pitti> RC bugs> well, 40 to go :)
[08:47] <pitti> well, 31 really, 9 are "fix committed"
[08:49] <pitti> ps aux|grep splash
[08:49] <pitti> ps ux
[08:50] <pitti> sudo usplash --pulse-logo
[08:51] <chrisccoulson> i'll have a look at the remaining RC bugs later and see if there are any i'm capable of fixing ;)
[08:51] <chrisccoulson> i'm wondering if the reporter of bug 452804 is actually being serious or not
[08:52] <chrisccoulson> pitti - did you have focus on the wrong window? ;)
[08:54] <pitti> chrisccoulson: meh, what happened? I started usplash, forgot -c, and my X fell over
[08:54] <pitti> had to reboot
[08:55] <pitti> chrisccoulson: did usplash pour some goo into IRC?
[08:55] <chrisccoulson> (8:49:46 AM) pitti: ps aux|grep splash
[08:55] <chrisccoulson> (8:49:47 AM) pitti: ps ux
[08:55] <pitti> eww, I typed those into VT1
[08:55] <pitti> chrisccoulson: did it also echo my password?
[08:55] <chrisccoulson> pitti - no, it didn't echo the password
[08:55] <pitti> of course you would say that!
[08:55] <pitti> :-)
[08:55] <pitti> thanks
[09:49] <dpm> pitti, here's the request I'm going to file -> http://ubuntu.pastebin.com/d75991fb8. A question about the dates mentioned there: which one do you think would work best for the release team while ensuring that translations are still in the LiveCD?
[10:04] <seb128> hello there
[10:06] <asac> hi seb128
[10:06] <seb128> hey asac
[10:06] <asac> thx for your polkit confirm
[10:06] <seb128> thank you for the quick fixing!
[10:06] <asac> ;)
[10:07] <seb128> brb another session restart after upgrade
[10:08] <asac> oh
[10:08] <asac> that reminds me that my only used user disappeared from the gdm login screen here ;)
[10:09] <seb128> re
[10:09] <seb128> karmic looks great ;-)
[10:09] <seb128> asac, you have a normal user not listed?
[10:09] <asac> seb128: yes. my "asac" user is gone here ;)
[10:09] <asac> but i have a special setup. for years i am using 501 as uid
[10:09] <seb128> asac, what uid has it?
[10:09] <asac> so i assume that you filteered that out
[10:09] <seb128> we filter on < 1000 now
[10:09] <asac> please allow 500+ ;)
[10:10] <seb128> 500-1000 are system users
[10:10] <seb128> or 500-999
[10:10] <seb128> rather
[10:10] <asac> well. my user is that and i have that for 10 years ;)
[10:10] <seb128> you can probably do "other" and type the name?
[10:10] <asac> yes. but thats a mess
[10:10] <asac> you dont want to tell me that i cannot select my user now?
[10:11] <seb128> I don't want to but ...
[10:11] <asac> < 500 is good
[10:11] <asac> i have 501
[10:11] <seb128> we got bugs complaining that system users were listed
[10:11] <asac> and i am sure it was a "normal" user account at some point
[10:11] <seb128> it's easy to change back, I've no strong opinion
[10:11] <asac> i just think that someone smart thought that things should now start with 1000 (probably 6 years ago)
[10:12] <seb128> bug  #427462
[10:12] <asac> "By convention, user IDs below 500 are reserved for system users. ... In"
[10:13] <asac> http://joomlapack.net/help-support-documentation/joomlapack-2x-documentation/siteadminintro-concepts.html
[10:13] <seb128> "100-999:
[10:13] <asac> just a random hit i get on google when typing: "system user 500"
[10:13] <seb128>     Dynamically allocated system users and groups. Packages which need a user or group, but can have this user or group allocated dynamically and differently on each system, should use adduser --system to create the group and/or user. adduser will check for the existence of the user or group, and if necessary choose an unused id based on the ranges specified in adduser.conf.
[10:13] <seb128> "
[10:13] <seb128> http://www.debian.org/doc/debian-policy/ch-opersys.html
[10:13] <asac> yes. thats debian
[10:13] <asac> maybe even linux
[10:13] <seb128> well, we follow debian there
[10:13] <asac> i am sure the general unix convention is 500
[10:14] <asac> right
[10:14] <asac> anyway. 500 is the right number. ;)
[10:14] <seb128> in one case we lists user we should not
[10:14] <asac> no
[10:14] <asac> i am sure debian has no system users > 500
[10:14] <seb128> in the other case we break people who manage to use a non standard debian uid
[10:15] <asac> yes. debian standard < unix standard imo
[10:15] <asac> look in your passwd
[10:15] <asac> do you see anything below 500 ;)
[10:15] <seb128> not if the change result to have random system users in the list
[10:15] <asac> err 500-1000 that is system user?
[10:15] <seb128> I've the sabayon one which was listed there
[10:15] <asac> as 500?
[10:15] <seb128> no, 9nn
[10:16] <asac> seb128: i think we should rather check if the user has a login-shell
[10:16] <seb128> but maybe that's a sabayon bug
[10:16] <seb128> asac, patches are welcome
[10:16] <asac> and if it allows login
[10:16] <seb128> feel free to do the change
[10:16] <asac> like: pulse:x
[10:16] <seb128> we just did it because people complained about having system users listed
[10:17] <asac> seb128: before there was no check?
[10:17] <seb128> it was checking uid > 500
[10:17] <seb128> we changed to > 1000
[10:17] <asac> hah
[10:17] <seb128> since that's what the debian policy documents
[10:18] <asac> so someone had some sense of reasonability ;)
[10:18] <asac> > 500
[10:18] <asac> thats the right way.
[10:18] <seb128> and people had issues with users in 500-999
[10:18] <seb128> well tell it to users who complained
[10:18] <asac> yeah i see
[10:18] <asac> i complain too
[10:18] <asac> those users are neglectable ;)
[10:18] <seb128> lol
[10:18] <asac> just kidding
[10:18] <seb128> you don't follow the policy
[10:18] <asac> but i think its worse to not show a user
[10:18] <seb128> I would say you are wrong
[10:18] <asac> than showing a few exceptional system users
[10:18] <seb128> change your uid to be > 1000
[10:18] <creatorzero> hi
[10:18] <asac> i think those folks should rather file bugs on them
[10:19] <asac> seb128: i am not wrong. i have that user id for 10 years
[10:19] <seb128> well I didn't think anybody would have normal users with uid < 1000
[10:19] <asac> and > 500 is the de-factor standard ;)
[10:19] <seb128> clearly that was wrong, there is one of those in the world
[10:19] <seb128> and he's there ;-)
[10:19] <asac> everyone having old installs probably has that
[10:19] <seb128> asac, 10 years is before ubuntu
[10:19] <asac> yes.
[10:19] <seb128> I don't think ubuntu created normal users with uid < 1000
[10:19] <asac> i kept the id because its easier for nfs etc.
[10:19] <asac> its _my_ id ... ;)
[10:19] <seb128> I would argue that we don't support upgrades from non ubuntu distros ;-)
[10:20] <asac> thats annoying
[10:20] <asac> still
[10:20] <asac> i dont log in regularly ... but ;)
[10:20] <seb128> you can enter your username in "other"
[10:20] <seb128> but right
[10:20] <asac> yeah. and that sucks
[10:20] <seb128> as said I didn't think anybody would get login broken due to that
[10:21] <creatorzero> i have got an acer aspire 5720 , ubuntu 9.04 installed with ati video driver enabled..when i'm watching a video like and mpg video and i made a double click to go fullscreen the screen become dark and i'm not able to do anything i need to restart manually the notebook..anyone can help me?thanks
[10:21] <asac> i think whoever did the > 500 was  good guy and had some decent knowledge about unix
[10:21] <seb128> you can undo the change if you want
[10:21] <asac> seb128: do you have the bug?
[10:21] <seb128> we can try to find an another way for the filtering based on bugs
[10:21] <asac> i want to check whats up there before saying i want to back this out
[10:21] <seb128> asac,  bug  #427462
[10:21] <seb128> asac,  bug  #427462
[10:21] <seb128> ups
[10:22] <seb128> asac, see r137 and r142
[10:22] <asac> r?
[10:22] <asac> in svn?
[10:22] <asac> ah bzr
[10:22] <seb128> no, bzr
[10:22]  * asac slow this morning
[10:23] <seb128> it's just 2 defines you want to change back
[10:23] <seb128> creatorzero, hi, try #ubuntu for user questions
[10:24] <creatorzero> thanks
[10:29] <asac> seb128: is that thing that decides that running as root?
[10:29] <seb128> asac, I don't understand the question
[10:29] <seb128> what thing? running what?
[10:29] <asac> seb128: nevermind. i wondered if gdm is running as root ... and if gdm is the process that actually decides on the UID
[10:30] <seb128> I think it's the greeter in this case
[10:30] <seb128> it runs as gdm user
[10:30] <seb128> and gdmsetup has logic for that too
[10:30] <asac> i dont understand who designed the code view thing in launchpad
[10:30] <seb128> to list users who can autologin
[10:30] <asac> but isnt it obvious that i want to go to the files referred to ;)?
[10:31] <asac> it doesnt do that ... just expands/collapses the diffs
[10:31] <asac> http://bazaar.launchpad.net/~ubuntu-desktop/gdm/ubuntu/revision/137#debian/patches/16_gdmserver_user_manager.patch
[10:31] <seb128> well we don't have the code in bzr
[10:31] <seb128> only the debian dir
[10:31] <asac> yes. but you have the patch
[10:31] <asac> i just wanted to navigate to the full patch
[10:31] <seb128> right
[10:31] <asac> oh
[10:31] <asac> that thing is a huge patch
[10:32] <asac> so that user_manager feature is ubuntu only?
[10:32] <seb128> gdmsetup is
[10:32] <seb128> the login screen one is r142
[10:33] <asac> kk ... thx
[10:51] <asac> ok i think i know how to properly do the system user test ... but only if running as root
[10:51] <asac> will take a stab at it when i find a minute ;)
[10:52] <asac> seb128: gdmsetup and the other gdm thing both run as root, right?
[10:52] <seb128> the greeter is running as gdm user
[10:52] <seb128> no
[10:52] <seb128> gdmsetup runs as user
[10:52] <seb128> and use polkit to get rights
[10:52] <seb128> the greeter runs as gdm
[10:53] <asac> it gets rights to write /etc/gdm/gdm.conf?
[10:53] <seb128> don't bother too much, change back to 1000
[10:53] <asac> no its ok
[10:53] <seb128> the greeter doesn't write anything
[10:53] <asac> i will keep it the current way
[10:53] <seb128> the greeter talk to the server to write changes
[10:53] <asac> which server is that?
[10:54] <seb128> but I think that the "what users to list" is purely a greeter thing
[10:54] <seb128> gdm
[10:54] <asac> ah ... greeter server
[10:54] <asac> seb128: what exactly does the gdmsetup part do?
[10:54] <seb128> gdmsetup talks to the gdm server to write the gdm.conf changes
[10:55] <seb128> ie it allow you to select an user to autolog
[10:55] <asac> ok
[10:55] <asac> thx
[10:55] <asac> good thing to fix for lucid ;) unless i get bored on weekend
[10:55] <seb128> ie gdmsetup is a simple thing, it handle all the actual work to the server
[10:55] <seb128> using dbus and polkit to get rights basically
[10:56] <seb128> and giving order over the bus
[10:56] <asac> yeah
[11:00] <asac> seb128: can you confirm that the patch fixes it in bug 438574 ... helps release teeam to allow the upload in ;)
[11:01] <asac> i will wait a bit if davidz has some comments etc. but otherwise would upload later today
[11:02] <asac> hmm. didnt you have a bug on your own?
[11:03] <seb128> asac, no, I looked for bugs matching my stacktrace before filling and found 2
[11:03] <seb128> I figured I didn"t need to file a duplicate
[11:03] <asac> kk.
[11:04] <seb128> asac, commented on the bug now
[11:04] <asac> thx
[11:04] <seb128> asac, you might want to just upload, davidz will not be online before some 5 hours anyway which will be late for you today
[11:07] <asac> true
[11:11] <chrisccoulson> hello seb128
[11:11] <seb128> hey chrisccoulson
[11:11] <seb128> how are you?
[11:11] <seb128> your work week is over?
[11:11] <chrisccoulson> yeah, not too bad thanks. a bit tired though. you?
[11:11] <chrisccoulson> my work week is over in 2 hours ;)
[11:19] <pitti> dpm: mentioned in the bug
[11:19] <dpm> pitti, I've just seen it, thanks a lot!
[11:22] <baptistemm> heya
[11:24] <chrisccoulson> hey baptistemm
[11:25] <baptistemm> hey chrisccoulson
[11:26] <asac> uploaded polkit
[11:27] <asac> we also had a second variant of that crash ... also fixed
[11:28] <baptistemm> hi asac
[11:28] <asac> baptistemm: hi
[12:15] <chrisccoulson> seb128 - i wrote a patch for the screensaver issue last night. kees said he was going to sponsor it at some point, but i don't know if you're interested in testing it too? i tested it for 20 minutes or so last night (continuously entering my password incorrectly) and i couldn't make it crash with the patch, but i'm not sure if i was just unlucky ;)
[12:16] <seb128> chrisccoulson, I will give it a try but not now I'm about to go for lunch
[12:16] <chrisccoulson> ok, no worries
[12:17] <chrisccoulson> the change is in bzr anyway
[12:19] <pitti> hey seb128
[12:19] <pitti> could someone please ty something for me?
[12:20] <pitti> cd /tmp; couchdb
[12:20] <pitti> and see if it crashes ("Crash dump was written to: erl_crash.dump")
[12:22] <seb128> hey pitti
[12:22] <seb128> Crash dump was written to: erl_crash.dump
[12:22] <seb128> pitti, ^
[12:30] <pitti> seb128: \o/ thanks
[12:31] <pitti> that means I didn't break it
[12:31] <seb128> pitti, is that a good thing?
[12:31] <seb128> oh ok
[12:31] <pitti> seb128: I changed erlang to build with wxwidgets
[12:31] <pitti> and with my version I still get a running couchdb
[12:33] <seb128> pitti, doesn't that mean that wwidgets needs to be promoted now?
[12:33] <seb128> do we really need that?
[12:33] <pitti> seb128: sorry, "without"
[12:34] <seb128> ok
[12:34] <pitti> seb128: bug 438365
[12:34] <pitti> wxwidgets is currently in component-mismatches, but we don't want it in main
[12:34] <seb128> right
[12:37] <Amaranth> pitti: all the compiz changes were done by one person, reviewed by another, and tested by me (and them of course)
[12:37] <pitti> Amaranth: my primary concern is the removal of the gconf backend, I asked in the bug
[12:38] <Amaranth> pitti: you're not subscribed to the bug though :)
[12:38] <seb128> pitti, btw robert_ancell argued for the podcast changes so I uploaded
[12:38] <Amaranth> oh, release team is
[12:38] <seb128> pitti, he said that some of the major distributors website will not work without those
[12:38] <pitti> Amaranth: I thought I sub'ed ubuntu-release
[12:38] <seb128> pitti, since the code is pretty specific to podcasts anyway it should be ok
[12:38] <seb128> pitti, but feel free to review as you want ;-)
[12:39] <pitti> seb128: I was going to ask him about that, but this is fairly intrusive, and the patches weren't acked upstream yet either
[12:39] <seb128> pitti, thanks ;-)
[12:39] <pitti> I'll have another look later
[12:39] <seb128> pitti, the gvfs one has been commited today slightly changed
[12:39] <seb128> pitti, I tend to trust robert_ancell code wise
[12:39] <seb128> he has been good work
[12:40] <seb128> anyway lunch time
[12:40] <seb128> bbl
[12:42] <pitti> seb128: do we need the changes that upstream did?
[12:45] <Amaranth> pitti: ok, commented
[12:52] <mac_v> mpt: hi... volume mute/ volume=0 bug > https://bugzilla.gnome.org/show_bug.cgi?id=598459#c9   , i think the dev is looking for some design suggestions..  [i'm not sure what to infer from last comment]
[12:52] <mpt> mvo, next week I will start revising the SoftwareCenter spec for v2. Is there any reason for us to archive the 1.0 spec, or should I just overwrite it?
[12:54] <mpt> mac_v, I don't have anything more to say there than what you've already said (and what I said in the comment you inked to)
[12:54] <mpt> +l
[12:55] <mac_v> ;)  well.. i dont know what to comment either.. so probably the icon wont change :/
[12:57] <Ng> WARNING: Unhandled message: interface=org.freedesktop.DBus.Introspectable, path=/, member=Introspect
[12:57] <Ng> what's that likely to be from?
[12:57] <mac_v> Ng: hi , is the gpm-mouse icon fixed now? i couldnt test it from my end :)
[12:58] <Ng> mac_v: yes thanks :)
[12:58] <chrisccoulson> Ng - no idea, that could come from absolutely anything
[12:58] <mac_v> cool :)
[12:58] <Ng> mac_v: I like the red hinting on the empty one :)
[12:58] <pitti> Amaranth: replied
[12:58] <mac_v> Ng: thanks :)
[12:58] <Ng> chrisccoulson: I'm trying out a newer bash-completion and I get it with every tab when doing scp, and I googled for it and there's a bug about vinagre saying it. Is it things assuming a newer/older dbus?
[12:59] <mvo> mpt: cool. there is no reason to keep the old stuff, my gut feeling is still to keep a copy of the 1.0 state, but I don't have any use-case or reason (other than that its cool to have backups)
[13:01] <Amaranth> pitti: and back :)
[13:01] <Amaranth> or not, stupid ISP/launchpad
[13:01] <chrisccoulson> Ng - it generally isn't anything to worry about. it just means that an application received a org.freedesktop.DBus.Introspectable.Introspect message, but it doesn't support introspection
[13:02] <mpt> mvo, ok, I'll save it as "Web Page, Complete" and as ?action=raw, and let Canonical backup handle it :-)
[13:02] <Ng> chrisccoulson: if it was just graphical apps I'd be fine with it, but it's quite annoying when it's spamming your terminals, and preventing you getting bash_completion's scp hook fixed for karmic ;)
[13:03] <Amaranth> *sigh*
[13:03] <Amaranth> Ok, not going to be commenting any time soon
[13:04] <pitti> Amaranth: just tell me here :)
[13:04] <pitti> Amaranth: is there a chance that some users actually use the gconf backend?
[13:04] <Amaranth> pitti: the only way to use the gconf plugin has been to edit /usr/bin/compiz
[13:04] <Amaranth> pitti: and none of the settings tools work when the gconf plugin is being used (they end up switching you back to the ccp plugin)
[13:05] <pitti> Amaranth: so why exactly was it removed now?
[13:06] <Amaranth> pitti: Because in the past if a user tried to load it (`compiz --replace gconf`) it would basically just ignore that because the ccp plugin was already being loaded. Now compiz loads all plugins specified on the command line and makes it impossible to unload them
[13:06] <Ng> aha, it's avahi-browse that's doing it
[13:06] <Amaranth> pitti: So now the gconf plugin is actively interfering with the ccp plugin and causing the issue mentioned in that bug report
[13:07] <pitti> Amaranth: ok, thanks
[13:45] <seb128> pitti, no opinion about gvfs I guess we could use the upstream version
[13:59] <dpm> pitti, now that ubuntu-docs is in language packs, does that change the workflow for translations in any way? If I understand it correctly, a new version of the ubuntu-docs package will have to be created with updated xml translations, which will then be imported and exported in the language packs
[14:00] <pitti> dpm: correct
[14:03] <seb128> pitti, is bug #453072 due to your recent changes?
[14:04] <pitti> seb128: yes, it is; we determined that eject cannot be "safely eject" by default, since there are some machines with internal usb drives (card readers)
[14:04] <pitti> if you "safely remove" them, they get disconnected from usb and you need a reboot
[14:04] <seb128> well, you don't have any way to know if the usb drive is a card readers or a key?
[14:04] <seb128> I know this bug
[14:04] <seb128> but having 3 options for a usb stick is ridiculous
[14:04] <pitti> seb128: bug 404185
[14:04] <seb128> we already had a bug that 2 options was confusing
[14:04] <seb128> unmount and eject is the same to users
[14:05] <seb128> so 3...
[14:05] <pitti> seb128: we don't know whether it's internal or external unfortunately :-(
[14:05] <seb128> which means you confuse 99% of users for a 1% case?
[14:05] <pitti> so the nautilus eject icon does eject now, but not safe removal
[14:05] <seb128> I can understand why but I would not call the bug fixed there
[14:05] <pitti> well, 404185 is, but not the general issue of course
[14:06] <seb128> having 3 items to eject an usb key makes no sense
[14:06] <seb128> how do we expect user to know which one to use?
[14:06] <pitti> well, they do different things; I don't know
[14:06] <seb128> pitti, do you have a bug number to track the issue?
[14:06] <pitti> we could entirely disable safe removal
[14:06] <pitti> and not make this availablle
[14:06] <seb128> pitti, what do they do different on an usb stick?
[14:07] <pitti> it's not a regression, just some devices need it to stop flashing lights and "unsafe to remove" warnings
[14:07] <seb128> what we want is basically a write flush on the stick
[14:07] <pitti> seb128: eject unmounts all and sends media eject command, which is enough for e. g. ipods
[14:07] <seb128> well for sure we don't need *3* option in usb keys context menus do we?
[14:07] <seb128> I don't even understand the difference
[14:08] <pitti> we could probably also get rid of umount if we have eject
[14:08] <seb128> I just want a "do whatever you want and give me my key" item there
[14:08] <pitti> the most prominent difference is that eject unmounts all partitiosn
[14:08] <pitti> seb128: use the eject icon in nautilus then :)
[14:08] <pitti> I think that's what most people want
[14:08] <seb128> why do we have an unmount out of cds?
[14:09] <kenvandine> most people don't know what unmount is
[14:09] <seb128> why do anybody want to unmount rather than eject a key?
[14:09] <dpm> pitti, ok, thanks (re: langpacks and ubuntu-docs)
[14:09] <pitti> seb128: corner case, if you only want to use one partition on an USB HDD; not that relevant, I guess
[14:09] <seb128> hum
[14:10] <seb128> there is really people who care to unmount one partition on a key they use?
[14:10] <seb128> what is the pratical interest there?
[14:10] <pitti> probably not on an usb stick, but on a hd there might
[14:10] <pitti> but I wouldn't call that very relevant
[14:10] <seb128> do we have a way to make the different between those devices?
[14:10] <pitti> I'd be fine with hiding umount for stuff that doesn't have media
[14:10] <seb128> ok
[14:10] <seb128> I will give it some thinking, not for karmic now anyway
[14:11] <seb128> pitti, thanks
[14:11] <seb128> pitti, btw the bug is a gvfs one right?
[14:11] <seb128> or nautilus?
[14:13] <pitti> seb128: gvfs I think
[14:13] <seb128> pitti, thanks
[14:14] <pitti> seb128: well, showing umount could be nautilus, I'm not sure
[14:14] <seb128> I don't really get the new option
[14:14] <seb128> the safely remove sounds like an unmount
[14:15] <seb128> but I will not bother for now
[14:15] <pitti> it's like eject plus additionally power off the usb controller
[14:15] <seb128> any reason eject couldn't do that by default?
[14:15] <pitti> it's what the eject button did until a week or so ago
[14:15] <pitti> seb128: internal usb devices
[14:16] <seb128> well, in those case you still have both options?
[14:16] <seb128> and if you pick the wrong one you are screwed?
[14:16] <pitti> we discussed it quite a bit, looked at dmidecode and USB classes etc. to figure out whether a device is internal
[14:16] <pitti> seb128: right, but the main concern was that the eject symbol in nauilus (bookmark bar) did that (which most people do, I figure)
[14:17] <seb128> how do you decide if the icon should eject or safely eject?
[14:17] <seb128> could that same logic be applied to make eject do whatever it should?
[14:18] <pitti> seb128: we can't decide it, that's the point
[14:18] <pitti> so it's always just normal eject now
[14:19] <seb128> we should maybe an yet another entry "I don't care and don't understand what you want, give me my key"
[14:19] <mac_v> kenvandine: Win7 now uses "dismount" so , pretty soon most users will know what 'unmount' is ;)
[14:19] <seb128> ;-)
[14:19] <seb128> half joking
[14:19] <pitti> hehe
[14:19] <seb128> I'm not a newbie but I've no clue which one to use now
[14:21] <seb128> pitti, the "eject" icon is what you use if you use browser mode and not right click on desktop icons
[14:21] <pitti> seb128: as I said, we could hide the "safe removeal" option entirely, if we don't particularly care about this
[14:21] <seb128> which is what most users do I expect
[14:21] <pitti> *nod*
[14:21] <seb128> nobody bothers opening a browser dialog to use the sidebar
[14:21] <mac_v> seb128: the unmount and new eject idea started from here :/ > https://bugzilla.gnome.org/show_bug.cgi?id=576587
[14:21] <seb128> mac_v, right, I've been following this bug
[14:21] <seb128> and it was "how can we display 1 item and not 2"
[14:21] <seb128> and now we have 3
[14:22] <mac_v> ridiculous ;)
[14:22] <kenvandine> way too confusing
[14:22] <seb128> I understand why we are there
[14:22] <seb128> we had cases broken before
[14:22] <seb128> so we unbroke those by confusing everybody else
[14:23] <seb128> we should try to do better next cycle though
[14:24] <pitti> so, show both for CD-ROMs, and just "eject" for everything else?
[14:24] <seb128> pitti, don't do anything for karmic
[14:24] <seb128> we tried that before I think
[14:24] <pitti> for lucid, I mean
[14:24] <seb128> cf upstream bug mac_v pointed
[14:25] <seb128> there was unhappy users because of the "I want to unmount a partition on usb disks"
[14:25] <seb128> or similar cases
[14:25] <seb128> I'm wondering if we should go for the easy way in nautilus
[14:25] <seb128> and tell those users to use gdu
[14:26] <seb128> since that's a corner case usually
[14:26] <mac_v> +1
[14:27] <mac_v> seb128: gvfs devs are most probably the 'unhappy user'  , some of the ideas in gvfs are too geek-centered rather than user-friendly ;p
[14:31] <seb128> mac_v, right, hackers are power users
[14:31] <seb128> that's expected
[14:31] <seb128> that's doesn't mean they don't listen to constructive comments
[14:47] <asac> mvo: is bug 452752 a bug at all?
[14:47] <asac>  ErrorMessage: package ubufox is already installed and configured
[14:48] <mvo> asac: no :(
[14:48] <asac> i only know that message if running apturl on something that exists
[14:48] <asac> mvo: ah. so its a false-positive apport trigger ;)?
[14:48] <mvo> asac: sorry, its a followup error, most likely something like bad happend before
[14:48] <mvo> yeah
[14:48] <mvo> let me look at the log
[14:48] <seb128> mac_v, do you know if the nautilus copy icon being colored is a known issue?
[14:48] <seb128> mac_v, do you know if the nautilus copy icon being colored is a known issue?
[14:48] <mvo> dpkg-deb: `/var/cache/apt/archives/openoffice.org-help-en-us_1%3a3.1.1-4ubuntu1_all.deb' is not a debian format archive^M
[14:49] <mvo> dpkg: error processing /var/cache/apt/archives/openoffice.org-help-en-us_1%3a3.1.1-4ubuntu1_all.deb (--unpack):^M
[14:49] <mvo>  subprocess dpkg-deb --control returned error exit status 2^M
[14:49] <mvo> ^--- asac that looks *very* unahppy
[14:49] <asac> hehe
[14:49] <asac> so whose bug is it that it got filed against ubufox?
[14:49] <seb128> mac_v, the one displayed in the notification area during copies
[14:49] <asac> apport hook?
[14:49] <asac> mvo: ?
[14:49] <mvo> we got a few of those, I get the growing fear that something with our kernel is odd, maybe ext4
[14:49] <asac> urgh
[14:49] <mvo> asac: that is a apt bug
[14:49] <asac> i dont want to know that ... remember?
[14:50] <asac> ok
[14:50] <mac_v> seb128: oh ,that the file operations , yeah.. but i think that would need a code change , to use a new label
[14:50] <mvo> scott had a issue the other day where a downloaded file was correupted when it was saved to disk
[14:50] <seb128> mac_v, do you know if there is a bug about it?
[14:50] <mvo> now I'm pretty confident in the code in apt that does the downloading/checksuming
[14:50] <mvo> I even created a fault injecting proxy to test that the checksum stuff is wokring
[14:51] <asac> mvo: maybe the .deb download was put there without being finished? is that possible?
[14:51] <mvo> that leaves something in memory->disk->memory
[14:51] <mvo> in theory it might, but apt will only move it out of partial/ once its completed
[14:51] <mvo> (and the sha256 matches)
[14:52] <mvo> but it will only match the downloaded stream, not the on-disk data
[14:52] <asac> mvo: but but ... move doesnt rewrite if its on same partition
[14:52] <mvo> (for efficiency)
[14:52] <asac> e.g. mv /var/..:/partial/a.deb /var/.../final/a.deb
[14:52] <asac> shouldnt do anything ... if it breaks that it should be unrelated to that op
[14:52] <mvo> yeha, my theory is that during  network->disk something happend
[14:52] <mvo> some corruption
[14:52] <asac> mvo: if you copy there is the likelyhood that the copy got killed
[14:53] <asac> so you need to rerun the checksum after copy
[14:53] <asac> in theory
[14:53] <mvo> so far the hash is only taken on the network stream
[14:53] <mvo> s/so far/currently/
[14:53] <mvo> but that ought to be sufficient :)
[14:53] <asac> huh? you said that you check the sum aginst partial?
[14:53] <asac> mvo: do you mv or cp from partial to archives?
[14:54] <mvo> it gets downloaded in partial and the hash is updated after each block, when the download is finished and the hash matches the downloaded file in partial/ is moved to final
[14:54] <mac_v> seb128: Bug #437532
[14:54] <mvo> partial/ is a dir
[14:54] <seb128> mac_v, thanks
[14:54] <asac> mvo: move == mv or cp+rm ?
[14:54] <mvo> rename()
[14:55] <mvo> (unless I miss something, I need to double check to be 100% certain)
[14:55] <mvo> but if its a copy, there might be a issue when a flush() returns too early for example
[14:55] <asac> yes. or the copy gets killed
[14:56] <mvo> oh, interessting thought
[14:56] <asac> next time you find it in there ... half state
[14:56]  * mvo nods
[14:56] <asac> like ... hit reset button if upgrade takes too long ;)
[14:56] <mvo> haha
[14:56] <mvo> right
[15:04] <seb128> pitti, btw my cdrom driver has a music player icon now
[15:04] <seb128> pitti, does your fix from the other day require a reboot?
[15:04] <seb128> it's on my laptop, I did restart my session but didn't reboot
[15:04] <pitti> seb128: a restart of dk-disks
[15:05] <pitti> ah, no, sorry
[15:05] <pitti> seb128: reboot is easiest, or an udevadm trigger
[15:06] <seb128> pitti, ok, so it's probably it
[15:06] <seb128> I will try later and let you know
[15:13] <dpm> pitti, in the documentation at https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation#Desktop%20Entries you updated that section because the X-GNOME- key should be the preferred one, but I see that the langpack.mk rule in Karmic still uses the X-Ubuntu- key. Shall I update the docs in the wiki accordingly, since currently all apps seem to still be using X-Ubuntu-?
[15:14] <pitti> dpm: X-GNOME is preferred nowadays, we need to update langpack.mk
[15:14] <pitti> thanks for spotting
[15:14] <pitti> dpm: updating in bzr right away, so that we don't forget
[15:15] <pitti> dpm: (done)
[15:16] <dpm> pitti, is that going to work seamlessly? I mean, there will be some packages in the system which will still have the X-Ubuntu- key until they are rebuilt with the new rule. Will glib (I believe it was) recognise both keys?
[15:17] <pitti> dpm: yes, our glib checks for both
[15:17] <dpm> pitti, ah, great
[15:17] <pitti> first X-GNOME, then X-Ubuntu
[15:17] <dpm> thanks
[15:19]  * seb128 is away now see you later
[15:20] <dpm> pitti, another question on that, IIRC if static translations are present, they take precedence over those in the mo files. Does that work on a per language basis? I mean, if I've got a .desktop file with only a few static translations in the system, but it doesn't contain e.g. 'de', although the German translation is present in the mo file, will the mo file translation be picked up anyway?
[15:23] <jcastro> asac: I did a talk last night at a LUG and someone had a palm pre and asked about tethering and I didn't know how to answer. So we just tried it and it all worked ootb with n-m. It was brilliant.
[15:23] <pitti> dpm: yes, it should work per-language
[15:23] <asac> jcastro: cool. through USB? karmic?
[15:23] <dpm> pitti, ah, great, thanks
[15:24] <jcastro> asac: yep, just showed up in n-m as palm pre and "Auto USB" and just worked. No one in the room could believe it.
[15:25] <asac> nice ;)
[15:25] <jcastro> asac: anyway I just wanted to pass that along, it was very impressive to see.
[15:25] <asac> thx
[15:25] <asac> nice to hear good feedback when always working on bugs, bugs bugs ;)
[15:25] <asac> tells me that something works at least :)
[15:26] <jcastro> well, you know how lug talks can be, I got pelted by pet bugs for like 2 hours so it was nice to end with something so "used to be impossible to get working in linux" live demo
[15:26] <asac> yeah i can figure
[15:26] <asac> did you take notes about the pet bugs? or were most really specific things?
[15:27] <jcastro> I've got good notes and will do a trip report
[15:27] <asac> cool
[15:27] <jcastro> every once in a while I'll go to a lug and they have very specific bug issues and whatnot, which is good
[15:27] <asac> jcastro: is your personal modem working ;)?
[15:27] <jcastro> I don't have one
[15:27] <asac> ah. tried phone?
[15:27] <jcastro> I don't even know where to find a landline these days
[15:27] <asac> jcastro: no. 3g modem
[15:27] <asac> ;)
[15:28] <jcastro> oh no, I used to have a friend that worked at a sprint store who would let me try a bunch but she moved away. :(
[15:28] <asac> too bad. thx!
[15:30] <asac> pitti: i updated the ipv4 RC bug in case you need that for release meeting
[15:30]  * pitti declares victory over usplash
[15:31] <pitti> superm1: should work for you now (with latest bzr)
[15:31] <pitti> asac: danke
[15:31] <asac> pitti: current status is that we still dont know when to reproduce that... but the other scary part (sebs reconnect when connection editor is opened)
[15:31] <asac> is fixed in polkit
[15:31] <pitti> sweet
[15:31] <asac> pitti: i wanted to close the bug actually bug there was a dupe just today :(
[15:31] <pitti> Riddell: can you please Kupdate https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus ?
[15:32] <asac> my hope is that the user upgraded to beta and got struck by one fo the many issues because of version mismatch and now filed it
[15:32] <pitti> asac: the polkit bug was not by any chance related to bug 445303?
[15:32] <pitti> mvo ^
[15:32] <asac> let me check.
[15:33] <pitti> asac: so, if it's not really reproducible, we can certainly downgrade it
[15:33] <asac> pitti: yes. i think thats the same
[15:33] <asac> pitti: yes. i think thats best. unless we get more filings. though if it strikes someone its most severity ... no connection
[15:34] <asac> which makes me feel it should be somewhere at least. if we get more dupes we might want to put the workaround into
[15:34] <pitti> asac: ok, setting to medium ok for you? (I'm about to)
[15:34] <asac> release notes
[15:34] <pitti> yes, makes sense
[15:34] <asac> pitti: i would say, keep it on high. but unmilestone or untarget from karmic
[15:34] <pitti> ok
[15:34] <asac> not sure what we do for things that might end up in release notes
[15:34] <asac> you probably know best
[15:35] <pitti> asac: usually you'd add an "ubuntu release notes" task
[15:35] <asac> ok ... maybe communicate that to release team
[15:35] <asac> we will decide before RC what to do
[15:35] <asac> is that ok?
[15:35] <pitti> asac: feel free to just add a stanza to https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview, I think you know best what to write there
[15:35] <pitti> asac: sounds good
[15:36] <asac> ok so dont change it today. lets look at that next week on monday/tuesday. maybe we will find the problem ;)
[15:36] <asac> pitti: so that update-manager bug is one falloff ... i think there should be lots of bugs. because if you used the official example
[15:36] <asac> you will free authority early
[15:36] <pitti> right, as the documentation says
[15:44] <azteech> need to see if I can get someones input if possible. Have two machines, one a 64bit AMD, and one 32-bit. Have successfully downloaded the updated 9.10 beta livecd and it verified with no errors against md5 checksum. The two computers I have are currently running 8.04 LTS 64-bit, and 9.04 on my secondary x8686 32-bit. Both these systems are connected via a KVM switch to a single monitor/keyboar/mouse. When I try to run livecd of
[15:47] <azteech> because this happens so early in the initialization step / install step, normal troubleshooting (lspci, x.org conf, etc.) are not even initialized yet. so can't use them to isolate the problem.
[16:30] <pitti> azteech: your first comment was cut after "When I try to run livecd of"...
[16:30] <pitti> which was exactly the part where you mention the actual problem, I guess
[16:36] <dobey> seb128, pitti: i need to get some food in me, but will have an ubuntuone-client upload ready in about 1.5 hours or so
[16:37] <pitti> dobey: ok; I will be gone at this time, but I'm sure there's someone in #u-devel or here who can sponsor
[16:53] <azteech> pitti: rest goes like this "When I try to run livecd of the beta 9.10 on either machine, the systems boots up fine until it gets to the video setup. Then I get "out of range" error on my monitor. When I attempt to do a straight install of the 9.10 on my secondary system, I receive the same error "out of range".  This tells me video bootstrap of the 9.10 is not being initialized properly, thus over driving my video card/monitor.
[16:53] <pitti> azteech: what video card?
[16:54] <pitti> I suppose it has trouble detecting the monitor frequencies through the kvm
[16:55] <azteech> It is a NvIdia GeForce 7400 series with 512  of ram. As for the KVM, thought of that. But, 9.04 and 8.04 don't have that problem.
[16:55] <pitti> ok, so no KMS problem
[16:56] <pitti> azteech: I'm afraid I don't have good advice here; bryce_ might
[16:56] <azteech> just so happens that I have the exact same card in both machines.
[16:57] <azteech> where did the last of my second input drop out? on my screen I see everything I uploaded onto channel.
[16:58] <pitti> azteech: as I said, "When I try to run livecd of"
[16:58] <azteech> still drops out there?
[16:58] <pitti> azteech: oh, your followup was okay
[16:59] <azteech> okay, thanks ...
[16:59] <azteech> interesting, didn't think there was a character limitation on input for channels. lol
[17:00] <azteech> pitti: thanks for looking at it and at least giving it some thought.
[17:02] <superm1> pitti, nice job! :)
[17:03] <pitti> superm1: I stared at that code for an hour, and then I started to dump palette entries for every single fading step; that finally showed the problem :)
[17:04] <azteech> bryce_ ping
[17:04] <azteech> pitti said you might be able to help with problem I outlined above.
[17:06] <Amaranth> azteech: what IRC client are you using?
[17:07] <azteech> pidgin..
[17:08] <azteech> v 2.6.1
[17:13] <joaopinto> azteech, there is a general limit defined on the IRC protocol, 512/line
[17:14] <azteech> joaopinto: thanks, didn't know that.
[17:14] <azteech> even old dog's can learn something new ... lol
[17:29] <pitti> good by all, need to run now
[17:30] <james_w> bye pitti
[17:30] <james_w> have a good weekend
[17:31] <james_w> asac: could you clarify your comment on bug 445303?
[17:31] <james_w> I'm rather confused about what other people think is going on there
[17:31] <asac> james_w: all i see was a potential freed policykit authority in the crash. now folks say that it doesnt use policy kit anymore
[17:31] <asac> so i wanted to know if there is a way to go back to the setup that had that problem
[17:32] <asac> so we can verify
[17:32] <james_w> what crash?
[17:32] <asac> well maybe not crash, but
[17:32] <asac> (polkit-gnome-authentication-agent-1:16914): GLib-GObject-WARNING **: cannot register existing type `_PolkitError'
[17:32] <asac> (polkit-gnome-authentication-agent-1:16914): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
[17:33] <asac> i just fixed a bug in polkit which might have fixed that warning ;)
[17:33] <asac> more i dont know about the bug.
[17:34] <james_w> ok
[17:34] <asac> so if its not easy to go back to aptdaemon ... just ignore it for this cycle
[17:34] <james_w> I'm not sure that's the cause
[17:34] <asac> feels like it
[17:34] <james_w> just test using software-center instead
[17:35] <asac> thats what i asked you to drop instructions how to verify this bug;)
[17:42] <asac> james_w: so yes. that thing fixed the agent crash
[17:42] <asac> james_w: so that means the bug shoud be fixed
[17:42] <james_w> asac: I still get those same warnings with the new version
[17:42] <asac> with crashing agent you never get a reply
[17:42] <asac> james_w: sure?
[17:43] <asac> i just updated it ... saw it before
[17:43] <asac> now i dont see it
[17:43] <asac> just running /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1
[17:43] <james_w> which binary package
[17:43] <james_w> ?
[17:43] <asac> before it crashed
[17:43] <asac> now it stayed there
[17:43] <james_w> and this bug is not an agent crash
[17:43] <asac> james_w: libpolk\*
[17:43] <asac> james_w: this bug is agent not replying ... which happens if it crashes for sure
[17:43] <asac> at least that how it felt on first glance
[17:43] <james_w> yes
[17:44] <james_w> but this isn't a crash from what I can see
[17:44] <asac> james_w: well. the guys posted it. with those warnings you can get everything
[17:44] <asac> as a matter of fact polkit wont work if you see those warnings
[17:44] <james_w> umm
[17:44] <james_w> not strictly true
[17:44] <asac> could be that the code doesnt catch if something returns a null and then never gets a callback
[17:45] <james_w> e.g. those that see the problem have it work some of the time and some not
[17:45] <james_w> but they always see those two warnings
[17:45] <james_w> I see the two warnings and have never seen this bug
[17:45] <asac> yes. could be everything. point is if you see this, you end up in a bad state
[17:45] <asac> and we didnt see nm crashes for all configs
[17:45] <asac> only sometimes
[17:45] <asac> probably racy too
[17:45] <asac> but well. the warnings are gone with latest polkit
[17:46] <asac> so its worth asking folks to verify imo
[17:46] <james_w> sure
[17:46] <asac> hmm
[17:46] <asac> i will cehck that code on monday
[17:47] <james_w> yeah, I still see the warnings with the new version
[17:47] <james_w> haven't rebooted though
[17:56] <asac> james_w: so is this still an issue somewhere at all? you said in software-center?
[17:57] <asac> if not i will not look on monday ;)
[17:57] <james_w> I have no idea
[17:57] <james_w> I have never hit this bug
[17:57] <james_w> and I don't even seem to be able to see the same things you do with the new versions
[17:58] <james_w> however, reports so far have suggested that this is a polkit-1 problem independent of whatever is using it
[17:58] <james_w> so it should be visible with s-c, or pkexec or whatever else if it still exists
[17:58] <james_w> and I suspect that this will not have fixed this issue
[18:00] <asac> james_w: i agree. the critical warnings are not fixed here. it just didnt happen a few times
[18:00] <asac> i will check on those and see what they are coming from
[18:01] <james_w> thanks
[18:01] <asac> could also be related how we link stuff ... but i stop speculating now
[18:54] <jcastro> rickspencer3: I never got that u1 invite, if you can find another way to get that video to me I think it'd be a nice weekend treat for the developerchannel
[18:54] <rickspencer3>   jcastro: rats
[18:54] <rickspencer3> will do today/tonight
[18:54] <rickspencer3> jcastro, will that work?
[18:55] <jcastro> no rush/emergency, triage me appropriately. :D
[18:55]  * rickspencer3 can ftp them to my server for the time being
[18:55] <rickspencer3> :)
[18:55] <jcastro> oh if you can ftp can send you the blip credentials
[18:55]  * jcastro will send a mail
[18:57] <rickspencer3> uh ...
[18:57] <rickspencer3> do I really come off as not being able to ftp?
[18:57] <jcastro> no, I am sending you the credentials so you can directly ftp to blip instead of going through me
[18:58]  * rickspencer3 notes pointy hair in mirror
[18:58] <rickspencer3> jcastro, ack
[18:58] <jcastro> and then the site does everything automatically
[18:58] <rickspencer3> sweet
[19:11] <dobey> hmm
[19:11] <dobey> anyone around to sponsor an upload for karmic? :)
[19:39] <chrisccoulson> dobey - sponsor an upload to main? (if so, i can't help you much, but i can if it is universe ;))
[19:41] <dobey> yes to main
[19:41] <dobey> seb said he would, but he's not online
[19:57] <diverse_izzue> asac, you're the network-manager guy right?
[20:42] <dobey> hrmm
[21:02] <diverse_izzue> do you usually expect an answer when you say hrmm dobey?
[21:03] <kenvandine> diverse_izzue, i think that is just his fingers thinking
[21:03] <kenvandine> :)
[21:03] <diverse_izzue> :-)
[21:14] <dobey> diverse_izzue: unfortunately i don't think anyone is around who can answer me right now :)
[21:15] <diverse_izzue> dobey, certainly not when all you ask is hrm
[21:15] <dobey> i didn't ask that
[21:15] <dobey> i stated it
[21:15] <dobey> :)
[21:33] <rickspencer3> diverse_izzue, what's up? It's night time in Europe on Friday after final freeze, so I hope asac is relaxing atm
[21:33] <rickspencer3> something  can help you with?
[21:33] <diverse_izzue> rickspencer3, how am i supposed to know in which time zone asac is? :-)
[21:33] <rickspencer3> you're not, I'm just telling you why he didn't answer
[21:34] <diverse_izzue> i just wanted to ask if karmic has the integration network-manager <-> bluetooth enabled. should my nokia mobile phone be recognised as a modem when i pair it?
[21:34] <rickspencer3> also, offering to help if possible
[21:34] <rickspencer3> hmmm
[21:35] <rickspencer3> diverse_izzue, I'm not sure what is supposed to happen, but I haven't heard about that feature
[21:35] <rickspencer3> though it would be sweet to be able to tether your phone via bluetooth
[21:36] <rickspencer3> diverse_izzue, did you try it and didn't do what you expected?
[21:36] <diverse_izzue> rickspencer3, fedora people (i think it was bastien nocera and dan williams) have been blogging about it, seems to be in f12, maybe already f11
[21:37] <dobey> diverse_izzue: /ctcp time asac will tell you what time zone he's in i think :)
[21:37] <dobey> well, at least, what timezone his irc connection is in
[21:38] <dobey> may not match up with physical timezone :)
[21:39] <tgpraveen> diverse_izzue: rickspencer3 it is in karmic.
[21:40] <tgpraveen> though currently it works with PAN and not DUN (or vice versa or something)
[21:40] <diverse_izzue> tgpraveen, but when i pair my nokia e51 with karmic, i'm not offered to use it as a modem. what goes wrong?
[21:40] <tgpraveen> so basically give it a a shot if it works it works :)
[21:40] <tgpraveen> hmm search on google for the exact blog post.
[21:41] <tgpraveen> and try asking someone on gnome- bluetooth channel or #nm
[21:41] <tgpraveen> maybe your phone doesn't support the reqd bt profile/ or you are doing it wrong
[21:42] <diverse_izzue> the blog post is here (but server down): http://blogs.gnome.org/dcbw/2009/07/10/unwire-with-networkmanager/
[21:43] <tgpraveen> diverse_izzue: do you reach till this stage successfully http://blogs.gnome.org/dcbw/files/2009/07/3-bt-pan.png?
[21:45] <diverse_izzue> tgpraveen, i don't get the checkbox
[21:46] <tgpraveen> ask on gnome-bluetooth's channel or #nm
[23:26] <awe> dtchen: do you have a minute for an alsa driver question?
[23:26] <dtchen> awe: shoot
[23:27] <awe> my macbook ( 5,1 ) doen't mute speakers when i plug in headphones.  that's an hda codec bug right?
[23:27] <awe> i'm running rtg's latest backports-alsa too
[23:28] <dtchen> awe: very well could be; the only way to prove it doesn't involve PA is to prevent PA from running
[23:28] <awe> ok, i'll play around with it over the weekend...
[23:29] <dtchen> awe: is it a Realtek or IDT codec?
[23:29] <awe> what's the easiest way to tell?
[23:29] <awe> i *think* it's realtek
[23:31] <awe> it's realtek ( lsmod, duh )
[23:33] <dtchen> awe: sorry, head -6 /proc/asound/card*/codec*
[23:33] <dtchen> but yes, lsmod|grep ^snd will also help ;)
[23:34] <awe> yea, both report the same ( whew ).  ;/
[23:34] <dtchen> which realtek?
[23:34] <awe> ALC889A
[23:35] <dtchen> oh blather
[23:36] <dtchen> is your ^Vendor Id 0x10ec0889?
[23:36] <dtchen> or 0x10ec0885?
[23:37] <awe> the latter ( ...885 )
[23:37] <dtchen> is ^Revision Id 0x100101 or 0x100103
[23:37] <awe> 103
[23:38] <dtchen> ok, and what's the ^Subsystem Id?
[23:38] <awe> 0x106b3f00
[23:38] <dtchen> yeah, you have a big fat entry in alc882_ssid_cfg_tbl[]
[23:39] <dtchen> /* FIXME: HP jack sense seems not working for MBP 5,1, so apparently * no perfect solution yet
[23:39] <dtchen> so, yeah, it's a codec issue; no need to chase down whether PA is involved
[23:40] <awe> ok, thanks for checking that out for me...
[23:40] <dtchen> np
[23:41] <dtchen> if you want, we can set aside some afternoon/evening at UDS to play with hda-analyzer and hda-emu to figure out which GPIO pins need to be twiddled
[23:41] <awe> sure, sounds like fun!  ;)
[23:41] <dtchen> hehe
[23:42] <cj> gar.  the printer search tool crashes while searching.  I know it won't find the printer by searching.  can I tell it not to?
[23:44] <rickspencer3> wow dtchen that was impressive for sure ;)
[23:44] <rickspencer3> awe has been asking about that for like 3 weeks now, I think ;)
[23:45] <awe> nah... just forgot my ipod when i went to the office today, and couldn't listen to ac/dc on my laptop w/out pissing off everyone else in the office!
[23:50] <dtchen> yeah, I'm missing AC/DC tonight to hack on sound bugs. Bah.
[23:50] <dtchen> they're playing less than two miles from me!
[23:50] <awe> open your windows, you'll probably be able to hear 'em!


[06:13] <ievans3024> may not be the place to ask, but anybody on here have experience getting X to work in arch-based distros?
[06:13] <ievans3024> this is the one place where i fail every time
[06:23] <bkerensa> ni ni
[06:26] <ievans3024> well, i got X up and running but now nobody can log in
[06:26] <ievans3024> i'll figure it out


[07:14] <erik_lonroth_> Hello people! Anyone here that knows where to figure out what url:s/domains that is used by "snap" to install juju? Our firewall/proxy is not being nice to me when trying to "snap install juju". Any pointers?
[11:33] <hloeung> erik_lonroth_: snaps are hosted on a CDN
[11:38] <hloeung> erik_lonroth_: maybe '068ed04f23.site.internapcdn.net.' ?
[11:41] <hloeung> that's from turning on query logging on my DNS resolver and running 'snap download juju'
[11:42] <hloeung> it also hits api.snapcraft.io before the CDN
[11:44] <magicaltrout> just won another local k8s contract, my ability to blag answers are second to none.....
[11:46] <rick_h> magicaltrout: lol awesome and congrats.
[12:12] <erik_lonroth_> hloeung: Thanx for trying to help out. I'm in the black here so I could use any help to compile a whitelist for the proxy.
[13:05] <stub> proof: E: config.yaml: ca does not conform to naming pattern
[13:05] <stub> Anyone know what that means?
[18:49] <magicaltrout> er right
[18:49] <magicaltrout> so I left my lovely k8s stack running last week
[18:49] <magicaltrout> this week
[18:49] <magicaltrout> I'm getting lots of this:
[18:49] <magicaltrout> manifold worker returned unexpected error: leadership failure: lease manager stopped
[18:49] <magicaltrout> on about 20 nodes
[18:49] <magicaltrout> what have i missed?
[18:53] <magicaltrout> https://paste.ubuntu.com/25473709/
[18:57] <magicaltrout> 2017-09-03 21:59:25 ERROR juju.worker.uniter.context context.go:675 could not write settings from "update-status" to relation 26: cannot write settings: read tcp <IP_ADDRESS>:37346-><IP_ADDRESS>:37017: i/o timeout
[18:57] <magicaltrout> does juju really suffer such a meltdown if there is a network issue?
[18:59] <tvansteenburgh> balloons, that mean anything to you? ^
[19:01] <balloons> magicaltrout, what does juju status say/show?
[19:01] <magicaltrout> i've rebooted the controller and the connections seem to be coming back
[19:01] <magicaltrout> but its spent 2 days in that weird failed state
[19:02] <magicaltrout> https://pastebin.com/ETBuBTS4
[19:02] <magicaltrout> before the restart it said that balloons
[19:03] <magicaltrout> back to green *phew* I don't like read
[19:03] <magicaltrout> red
[19:03] <balloons> yea, a bunch of failed workers.
[19:03] <balloons> curious how it got that way
[19:03] <magicaltrout> that said, the network was fine, I could ssh around from the controller to other nodes and stuff
[19:03] <magicaltrout> so I dunno why it got so sad for 2 days straight
[20:42] <magicaltrout> cicleci for juju builds is possibly the best thing I've ever found
[20:43] <magicaltrout> and snap builds for that matter
[20:44] <rick_h> magicaltrout: charming circleci? I was going to play with that at one point but it was missing something I needed. /me tries to remember...
[20:47] <magicaltrout> https://github.com/spiculedata/circleci-juju i wrote a simple dockerfile for it rick_h
[20:47] <magicaltrout> doesn't support resources yet
[20:47] <rick_h> magicaltrout: nice
[20:48] <magicaltrout> https://pastebin.com/1PrpjrP6
[20:48] <magicaltrout> build files look like that
[20:48] <magicaltrout> it can clearly be cleaned up and extended a bit, does the job nicely though for per commit builds of stuff
[23:06] <bdx> can I specify a subnet to bootstrap to?
[23:06] <bdx> for AWS
[23:06] <bdx> I thought I saw that land
[23:06] <bdx> rick_h: ^
[23:08] <rick_h> bdx: yea should be able to in 2.2.2
[23:08] <bdx> oh nice
[23:08] <rick_h> Thought it was in there.
[23:08] <bdx> yeah I thought so too
[23:09] <bdx> jam: ^?
[23:17] <bdx> found it https://bugs.launchpad.net/juju/+bug/1659640
[23:17] <mup> Bug #1659640: Juju needs to support specifying subnets for controller <juju:Fix Released by jameinel> <https://launchpad.net/bugs/1659640>
[23:18] <bdx> aweeeee it works too :)
[23:18] <bdx> that is really exciting
[23:18] <bdx> I've been cursing that bug for a long time
[23:19] <bdx> very nice get deterministic bootstraps
[23:19] <bdx> I feel so at peace


[00:06] <jelmer> hmm, a branch name from StevenK that doesn't make me go "WTF?"
[00:06]  * jelmer is disappointed
[00:06] <StevenK> jelmer: Which one?
[00:07] <jelmer> StevenK: refactor-imports-redux
[00:07] <StevenK> If it doesn't make you go WTF, Diff against target: 11295 lines (+1298/-1451) 531 files modified will
[00:08] <wgrant> sinzui: Hm, so just launchpadstatistic, librarian, logintoken and temporaryblobstorage left.
[00:08] <lifeless> poolie: we do more than 1M pages a day, we'd blow past their taster-account in no time ;)
[00:08] <wgrant> sinzui: I have a branch from a couple of weeks back for temporaryblobstorage.
[00:08] <StevenK> wgrant: sinzui was going to tackle logintoken
[00:23] <poolie> lifeless, how can i get the raw form of an oops?
[00:23] <poolie> or anyone
[00:33] <lifeless> from where
[01:17] <StevenK> wallyworld__: O hai. https://code.launchpad.net/~stevenk/launchpad/productset-all-lies/+merge/86314
[01:17] <wallyworld__> StevenK: looking now
[01:19] <wallyworld__> StevenK: any tests to amend?
[01:19] <StevenK> Not that I could see
[01:19] <wallyworld__> ec2 will tell us i guess
[01:19] <StevenK> Tempted to just -vvm registry
[01:19] <lifeless> sure there is a test to add ?
[01:20] <StevenK> I'd be surprised if ProductSet:+all wasn't tested by some doctest
[01:20]  * StevenK runs registry tests
[01:20] <wallyworld__> StevenK: i've +1'ed it but it would be cool if there were a doc test that could be added to
[01:20] <wallyworld__> or whatever
[01:59] <lifeless> poolie: :/
[02:31] <poolie> lifeless, ?
[02:31] <poolie> i found it on disk on devpad
[02:31] <poolie> why the frownie?
[02:32] <lifeless> I may have misinterpreted your answer to my reply to your advert for bson-dump
[02:33] <lifeless> ELONGCONTEXT
[02:33] <poolie> oh
[02:33] <poolie> i agree it would be good to do
[02:33] <poolie> i don't know why i didn't put it elsewhere in the first place
[02:33] <poolie> it was a while ago
[02:33] <poolie> perhaps all the external oops stuff seemed too much in flux?
[02:33] <poolie> or there were too many options for where to put it, so i took a lame default
[02:34] <lifeless> I felt, apparently wrongly, that you were being a bit uhm, 'well I've done, nyar'.
[02:35] <lifeless> the perils of low bandwidth comms
[02:35] <poolie> ah, not really
[02:35] <lifeless> poolie: I'd really like to delete utilities/*
[02:35] <poolie> feeling a bit "omg so few days before holidays etc"
[02:35] <poolie> if you tell me a specific place to move it to that will help
[02:35] <lifeless> heh, fair enough.
[02:36] <poolie> i guess, something that knows about bson encoding and will be installed for all developers
[02:36] <poolie> i think splitting stuff is good but a minor consequence is that 'where do i do this' gets a bit harder
[02:36] <lifeless> I'd put it either in oops-datedir-repo or oops-tools itself
[02:39] <lifeless> its not urgent to move it
[02:40] <lifeless> if you're busy with other stuff in the holiday lead up, just ignore it.
[03:00] <poolie> i'll move it to oops-tools
[03:22] <StevenK> from bzrlib.plugins.builder.recipe import RecipeParseError
[03:22] <StevenK>     ImportError: No module named builder.recipe
[03:22]  * StevenK peers
[03:30] <jtv> StevenK, wgrant: I'm sorry to hear that I broke buildmaster again.  Never expected there'd be no missed spots at all, but didn't expect this many either.
[03:30] <StevenK> Did Gavin land the fix?
[03:31] <StevenK> jtv: The test coverage of buildd-master is just *horrid*.
[03:32] <StevenK> Ah, reverted in r14552.
[03:32] <StevenK> But marked with the bugs, and not incr. Sigh.
[03:32] <jtv> Should that be incr?
[03:33] <jtv> I completely forgot about that tag.
[03:33] <StevenK> jtv: You're rolling back the code, so I guess the next step is fix the three bugs and land it again.
[03:34] <jtv> Well I'm not rolling anything back personally; I have to go back to clearing out the house.
[03:34] <jtv> But yes, I'm afraid that's the process.
[03:34] <StevenK> jtv: If so, our process says the 3 bugs should be closed. Except they won't be fixed.
[03:35] <jtv> Oh.
[03:35] <wgrant> So, PQM's been whinging about a conflict for 6 hours now.
[03:35] <StevenK> jtv: The qa-tagger will tag them needstesting, they'll get marked untestable, and rolled out.
[03:35] <wgrant> Is someone going to fix that at some point?
[03:36] <StevenK> I'm trying to sort out ImportError: No module named builder.recipe
[03:36] <jtv> StevenK: the bit you said about qa-tagger is what will happen regardless, no?
[03:36] <StevenK> jtv: Yes, but if was marked incr, the qa-tagger won't slam the bugs to Fix Committed.
[03:37] <jtv> Ah, now the pieces come together.
[03:38] <jtv> But I thought you said the rollback should be [incr], not the fixes themselves?
[03:39] <StevenK> jtv: Right. The rollback will be marked 'as part of this bugs fix', and then when the fixes land properly, the bugs should hit Fix Committed.
[03:39] <jtv> But you said the 3 bugs should be closed, withing being fixed..?
[03:42] <StevenK> jtv: No, I said that what was likely to happen due to the lack of incr.
[03:45] <jtv1> StevenK: you said "if so, the process says the 3 bugs should be closed."  What was the "if so" referring to?
[03:46] <StevenK> jtv1: I can see we are talking past each other. I explained what would likely happen, and then shifted to talking about what should have happened instead.
[03:47] <jtv1> Ah, I think I get it now.  Thanks.
[04:01] <StevenK> Is checkwatches safe to run on qas?
[04:04] <wgrant> StevenK: Not really, no.
[04:04] <wgrant> StevenK: And it wouldn't be a very useful test anyway.
[04:05] <StevenK> wgrant: Okay. Safer to qa-untestable my checkwatches branch?
[04:05] <wgrant> I think so.
[04:10] <StevenK> wgrant: Looking at db-devel versus stable
[04:17] <poolie> lifeless, hm putting this in with the daemon seems not quite right
[04:20] <StevenK> wgrant: PQM silenced. Hopefully.
[04:28] <poolie> i'll put it in python-oops
[04:31] <wgrant> poolie: Doesn't it belong in oops-datedir-repo?
[04:31] <wgrant> I didn't think python-oops knew about BSON.
[04:32] <poolie> it mentions it in the docs but it doesn't use it in the code
[04:32] <wgrant> It doesn't depend on bson.
[04:33] <wgrant> That's all in datedir-repo/amqp
[04:33] <poolie> but it does not seem like you should need the repo code to inspect an oops file
[04:33] <poolie> i could make a new package
[04:33] <wgrant> Why not?
[04:33] <wgrant> python-oops doesn't do serialisation.
[04:33] <poolie> it seems like overkill for what is basically one line of code
[04:33] <wgrant> "oops file" is a concept that's only part of datedir-repo.
[04:34] <poolie> there are two potentially separate aspects
[04:34] <poolie> serializing as bson
[04:34] <poolie> and writing into per-date directories
[04:34] <poolie> you could reasonably have the first without the second
[04:35] <poolie> indeed if you just download one oops you probably will
[04:35] <wgrant> Sure, but python-oops deliberately doesn't know about serialisation like that.
[04:35] <wgrant> That's left to the repository implementations: datedir-repo and amqp.
[04:36] <poolie> amqp has its own separate serialization?
[04:37] <wgrant> It's BSON. I believe it uses datedir-repo's BSON serializer.
[04:37] <poolie> foo
[04:37] <wgrant> All roads lead to datedir-repo :)
[04:37] <poolie> python-oops says in the readme it defines a serialization
[04:38] <poolie> though i suppose it is ambiguous what 'the oops project' means
[04:39] <poolie> so that's why i just put it in utilities/.
[04:39] <wgrant> I think python-oops' docs are out of date.
[04:39] <wgrant> datedir-repo was extracted in r9
[04:43] <poolie> hm, so
[04:44] <poolie> i don't know
[04:44] <poolie> having the format be separate from the serialization seems good
[04:44] <poolie> having no comment at all about what serialization seems dumb
[04:44] <poolie> in practice multiple trees assume it is bson
[04:44] <wgrant> No.
[04:45] <wgrant> Multiple repository implementations use BSON.
[04:45] <wgrant> datedir-repo has an option to write out rfc822 as well.
[04:45] <wgrant> And it will read it perfectly happily.
[04:46] <wgrant> amqp could be changed to use pickles if you were sufficiently misguided, without affecting datedir-repo.
[04:46] <poolie> true
[04:46] <poolie> so there's no reason this should live in one of them rather than the other
[04:46] <wgrant> Well.
[04:46] <wgrant> I think it makes sense in datedir-repo.
[04:46] <wgrant> Since amqp's bson doesn't ever hit the disk as a file.
[04:47] <wgrant> It's purely encoding as it goes into rabbit, and decoding as it comes out.
[04:47] <wgrant> (it's then usually handed off to datedir-repo, where it's reencoded and written out into a file)
[04:47] <poolie> yeah i see
[04:47] <wgrant> So I think this script belongs in datedir-repo.
[04:48] <poolie> and if python-oops-tools offered an option to download it, it would get reserialized again there
[04:48] <wgrant> Possibly.
[04:48] <wgrant> But maybe not.
[04:48] <wgrant> I think oops-tools is pretty tied to datedir-repo.
[04:49] <wgrant> Whereas amqp/datedir-repo/oops are very nicely separated.
[04:49] <wgrant> They actually have sensible interfaces, and work within them!
[04:50] <poolie> you know what, i'll just make it separate
[04:51] <wgrant> I think datedir-repo :) But ok.
[04:53] <wgrant> StevenK: Did you run that through ec2?
[04:53] <StevenK> wgrant: Which? The imports branch?
[04:53] <wgrant> Yes.
[04:53] <StevenK> Yeah, I did
[04:53] <wgrant> Hm.
[04:53] <StevenK> Why?
[04:54] <wgrant> A naive global format-imports should have broken stuff unless you were very lucky.
[04:54] <wgrant> Due to lp.codehosting's side-effects.
[04:54] <wgrant> Although I guess it is alphabetically early.
[04:54] <StevenK> There were 4 failures on ec2, which I fixed before lp-landing
[04:54] <wgrant> So it may be OK.
[04:59] <StevenK> wgrant: Still nervous?
[05:00] <wgrant> StevenK: Slightly.
[05:01] <StevenK> wgrant: I can forward you the failure mail if it will ally your concerns.
[05:08] <poolie> and there are at least two different python modules called 'bson'
[05:08] <wgrant> poolie: Yes :/
[05:08] <wgrant> And at least one of them is very buggy.
[05:08] <wgrant> (the one we use)
[05:12] <poolie> :)
[05:29] <poolie> wgrant, lifeless, https://code.launchpad.net/~mbp/python-oops-datedir-repo/bsondump/+merge/86338
[09:08] <bigjools> good morning
[09:09] <AutoStatic> Good morning
[09:11] <danhg> Morning all
[09:22] <AutoStatic> Some colleagues have asked me if I could set up an in-house Launchpad server so they could use it for their projects. They're probably only going to use the bugtrack, blueprint and repository functionality. I'm wondering though if Launchpad isn't a bit overkill then. What's your advise? I already set up a bugtracker for them (MantisBT), a Wiki for their blueprints and setting up a repo is not much work either.
[09:23] <StevenK> bigjools: Hai. Will you have a chance to do your QA today?
[09:24] <bigjools> StevenK: hopefully! I got a bit blindsided yesterday
[09:24] <StevenK> Yes, that's why I didn't bug you then. :-)
[09:24] <bigjools> I have a theory about poppy
[09:25] <StevenK> It is horribly, horribly broken and needs to die?
[09:25] <bigjools> well you wrote it :)
[09:25]  * bigjools just hacked on the FTP bit
[09:26] <StevenK> Better than continuing to use Zope's horrible excuse for an FTP server.
[09:26] <StevenK> bigjools: What is your theory?
[09:27] <bigjools> StevenK: the ssh checks connect to the appservers to get the authorisation
[09:28] <bigjools> when we have FDT, the XMLRPC connection fails
[09:28] <bigjools> after that, it continues to fail forever until restarted
[09:28] <bigjools> not sure why, but meh, Twisted
[09:28] <bigjools> the swap death was caused by someone using a loop to connect
[10:54] <jml> anyone developing on precise?
[10:54] <jml> AutoStatic: I'd recommend *not* running Launchpad locally.
[10:55] <AutoStatic> jml: Yeah, we figured that out too: https://answers.launchpad.net/launchpad/+faq/920
[10:55] <jml> AutoStatic: it's pretty huge and the operational cost is non-trivial, even at low scale.
[10:56] <bigjools> allenap: in the tests in your branch, it's probably worth refactoring the bit that sets properties on objects in a r/w transaction
[10:56] <jml> AutoStatic: cool.
[10:56] <allenap> bigjools: Erm, which bit?
[10:56] <jml> AutoStatic: so, I'm not 100% sure what your question is then :)
[10:57] <allenap> bigjools: Like in test_handleStatus_OK_sets_build_log?
[10:57] <bigjools> allenap: line 72/83 of the diff
[10:57] <bigjools> allenap: I suspect we'll need to do that a lot more in the future
[10:58] <allenap> bigjools: I don't know what a better way would be. I could instead enter read-only mode in each test individually (via a fixture) I guess.
[10:58] <bigjools> allenap: I was thinking just a test helper
[10:58] <bigjools> like setattr
[10:58] <bigjools> but does the whole transactionny thing
[10:59] <allenap> bigjools: With the removeSecurityProxy thing too I assume.
[10:59] <bigjools> allenap: no, the caller can do that
[10:59] <AutoStatic> jml: Well, I got an instance running locally here and my question was more or less a stepping stone to some other questions
[11:00] <allenap> bigjools: Okay, I think I have a cool way to do that.
[11:00] <bigjools> allenap: of course :)  cheers
[11:01] <AutoStatic> jml: So I'm going to wipe out that local launchpad and convince my colleagues that they should look for something else
[11:02] <jml> AutoStatic: ok.
[11:08] <jml> bwahahaha
[11:09] <jml> Python 2.6
[11:09] <jml> sorry.
[11:09] <jml> good luck with that.
[11:16] <gmb> Argh. My connection drops out for ten minutes and when I get back bigjools has done the review I was doing. It's going to be one of those someone-else-does-all-the-work OCR days, is it?
[11:17] <gmb> (Also, he did a better job of it)
[11:17] <gmb> (Which galls)
[11:18] <allenap> jml: I've had a bash at getting Launchpad built on Precise, but I lost interest (it was late). Seems like the cool kids are using a schroot (which I am) or an LXC.
[11:18] <allenap> (running Lucid)
[11:19] <bigjools> gmb: shurely shome mishtake :)
[11:20] <nigelb> What's the firefighting section about?
[11:20] <nigelb> (in the topic)
[11:21] <bigjools> if we're in the middle of an incident
[11:21] <nigelb> ah. It makes topic. Nice.
[11:21]  * bigjools just added a million people on G+ and may live to regret it
[11:23]  * nigelb just searched on G+ for "bigjools"
[11:23] <nigelb> Dammit.
[11:23] <allenap> bigjools, gmb: Thank you both for the reviews :)
[11:24] <bigjools> nae prob
[11:35] <allenap> bigjools: Fwiw, this is what I did to factor out the things you suggested: http://paste.ubuntu.com/776193/
[11:37] <bigjools> allenap: not so much as a refactoring as a rewriting :)
[11:38] <allenap> bigjools: Well, I'm already using it in my next branch, and will probably in the one after that :)
[11:38] <bigjools> heh
[11:39] <jml> allenap: I'm not suggesting you should actually make this change now, but it might be more re-usable as a Fixture.
[11:40] <allenap> bigjools: How do I go about QAing the revert I did? Or do we just say it's fine because it's approximately already on cesium.
[11:40] <allenap> ?
[11:41] <allenap> jml: Yeah, you're right. If it causes enough friction I'll change it.
[11:41] <bigjools> allenap: untestable
[11:42] <allenap> bigjools: Cool.
[11:47] <cjwatson> gmb: any further thoughts on my QA suggestions for https://code.launchpad.net/~mvo/launchpad/maintenance-check-precise/+merge/82125 ?
[11:49] <gmb> cjwatson: No, no further thoughts (sorry, meant to reply the other day but forgot after a reboot). Could you take care of QAing if for me? I'll make sure it lands today or tomorrow.
[11:49] <cjwatson> modulo holiday, yes I can
[11:49] <gmb> Excellent, thanks.
[11:52] <rick_h__> ./topic
[12:21] <jml> hmm.
[12:22] <jml> so I have a clean lucid schroot for building packages. Can I somehow leverage that to make an schroot dedicated to hacking on Launchpad?
[12:40] <cjwatson> you could copy the source directory and add a new entry in /etc/schroot/chroot.d/ for it
[12:41] <cjwatson> and drop the unioniness
[12:41] <cjwatson> I use a 'lucid-lp' schroot
[12:42] <jml> cjwatson: thanks.
[12:42] <jml> (also, my next laptop will have an SSD)
[12:56] <jml> hmm. I should probably do something like this for each Canonical-deployed project I work on.
[13:49] <jml> bzrlib.errors.ConnectionReset: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[13:49] <jml> got this trying to fetch bzr-git w/ update-sourcecode
[13:50] <jml> never mind.
[14:00] <al-maisan> jml: the /etc/resolv.conf in your chroot might be out of date..?
[14:01] <rick_h__> gmb: got a sec for review? https://code.launchpad.net/~rharding/launchpad/sort_labels_894744/+merge/86287
[14:01] <al-maisan> jml: try "sudo cp /etc/resolv.conf <path-to-chroot>/etc/resolv.conf" and see whether that helps
[14:01] <cjwatson> benji: I noticed that in the three branches of mine you reviewed yesterday, you left an Approved comment but didn't set the MP to Approved; was that deliberate?
[14:02] <benji> cjwatson: generally the MP initiator sets it to approved, sometimes they might be getting a DB review too or a UI approval
[14:03] <benji> I set the other one to approved because I was landing it and the machinery won't land unapproved branches.
[14:03] <cjwatson> oh, I didn't know that, my reviewer's always done it for me before
[14:03] <cjwatson> probably because I've always explicitly asked for landings :)
[14:07] <cjwatson> benji: ah, and I can't set the MP to Approved because I'm not in ~launchpad
[14:07] <cjwatson> benji: any chance of landings for always-index-d-i and sign-installer, then, if you have a chance?  It might be best to leave new-python-apt for a bit as it collides with https://code.launchpad.net/~mvo/launchpad/maintenance-check-precise/+merge/82125 and this way I do the merge rather than making somebody else do it
[14:07] <benji> heh, well that would make it harder
[14:09] <benji> cjwatson: sure, I'll start the landing of those in a bit
[14:10] <cjwatson> great, thank you
[14:13] <gmb> rick_h__: Sure thing; looking now.
[14:13] <rick_h__> gmb: ty much
[14:40] <gmb> rick_h__: Approved.
[14:46] <rick_h__> gmb: awesome, thanks
[16:30] <benji> I'd appreciate it if some kind soul would review this branch: https://code.launchpad.net/~benji/launchpad/bug-903532/+merge/86426
[16:30] <benji> if that kind soul has some translations knowledge, it would be even better
[16:49] <sinzui> benji, I ca take it
[16:50] <benji> sinzui: cool, thanks
[16:52] <sinzui> benji, r=me
[16:53] <benji> sinzui: thanks
[20:42] <lifeless> gary_poster: I'm around for a bit if you want to talk oopses more
[20:43] <gary_poster> thanks lifeless on call
[21:44] <wallyworld> sinzui: jcsackett: can we mumble now?
[21:44] <sinzui> yes
[21:45] <wallyworld> sinzui: fucking mumble is doing it's thing again where it consumes all my cpu. i have to reboot
[22:04] <james_w> anyone want to take a look at https://code.launchpad.net/~james-w/launchpad/bpph-binary-file-urls/+merge/86470 ?
[22:10] <poolie> o/ james_w
[22:10] <poolie> hi all
[22:11] <james_w> hi poolie
[22:38] <dobey> hey poolie
[22:53] <huwshimi> On the deployable revisions page it says "Revision 14556 can be deployed: orphaned". Does that mean I can't qa it?
[22:58] <lifeless> either it has no bug linked, or the bug has been closed already
[22:58] <lifeless> if its the latter, you can reopen the bug
[23:14] <huwshimi> lifeless: Will it get picked up by the qa tagger etc. then?
[23:15] <huwshimi> lifeless: Should it be Fix Committed or will any status other than  Fix Released do?
[23:21] <poolie> ok now i've played with juju it is annoying me that launchpad doesn't use it
[23:23] <jelmer> poolie: :)
[23:26] <poolie> jelmer, i just talked to flacoste about bug 795025
[23:26] <_mup_> Bug #795025: no way to gracefully disconnect clients and shut down the bzr server <canonical-losa-lp> <hpss> <launchpad> <ssh> <Bazaar:Fix Released by jameinel> <Launchpad itself:Triaged> < https://launchpad.net/bugs/795025 >
[23:26] <poolie> istm there is a safer way to do it
[23:26] <poolie> which is to have a signal to tell the processes to just stop listening
[23:26] <poolie> then we can start a new one
[23:34] <jelmer> poolie: will that work with haproxy?
[23:34] <poolie> i think so?
[23:34] <poolie> haproxy will detect that it's down?
[23:34] <jelmer> I haven't looked at it, so not exactly sure how it's communication with services works
[23:35] <jelmer> ah, so... so we shut the existing one down and then when haproxy starts another one that's using the new code?
[23:35] <poolie> i think it's some combination of: seeing if the port is listening, plus pinging a separate http port that reports on the status
[23:35] <poolie> more precisely:
[23:36] <poolie> we tell the existing one "stop accepting connections", and it closes its listening socket
[23:36] <poolie> and then haproxy notices it's down, i guess
[23:36] <jelmer> that makes sense
[23:37] <poolie> and then we start a new instance listening on the same port, which will be running the new code
[23:37] <poolie> then the old process can either exit by itself when all the connections are done
[23:37] <poolie> or the sysadmins can kill it if they want
[23:44] <lifeless> poolie: uhm, thats not sufficient
[23:44] <poolie> because?
[23:45] <lifeless> because having the old code running for several weeks will play havoc with things like upgrading xmlrpc verbs
[23:45] <poolie> ..?
[23:45] <poolie> like, removing old verbs on internal xmlrpc that the old code uses?
[23:46] <lifeless> yes, or rearranging things; things that you would normally do a server change, change client, cleanup old code sequence
[23:46] <lifeless> this depends on being confident that the client is deployed
[23:46] <poolie> mm
[23:47] <lifeless> not to mention that we would like to free disk space from old deploys.
[23:47] <poolie> so to have loose coupling we would want to not have those things required to happen in too short of a time window
[23:47] <poolie> anyhow, after that time, we can just kill the old procesess
[23:47] <poolie> the client should cope
[23:48] <lifeless> right, we can allow a few hours for the old processes to gracefully go away, which is what the current plan aims at
[23:48] <lifeless> we don't want to interrupt someones 6 hour epic initial push, after all.
[23:48] <poolie> right
[23:49] <poolie> so my plan is
[23:49] <lifeless> we don't want idle heavyweight processes hanging around indefinitely either, which means a way of killing them while idle, which implies the client coping
[23:49] <poolie> i think we can do this in two steps
[23:49] <poolie> 1- move new connections on to the new process
[23:50] <poolie> or rather, accept new connections from the new process
[23:50] <poolie> 2- boot off existing clients
[23:50] <poolie> 2 is a bit messy becaues
[23:50] <poolie> some clients won't cope well
[23:50] <poolie> and it will take unbounded time to get there
[23:50] <poolie> and it's just generally more risky
[23:50] <lifeless> mmm
[23:51] <lifeless> remember we have some fixed paths on disk for the front-forking IPC calls, and we also have N front-end and N forking services to restart
[23:51] <lifeless> doing 1 without waiting for 2 is more complex and doesn't really buy us anything
[23:51] <lifeless> we're still not done-done until 2 has happened
[23:52] <poolie> so doing only 1 will let us bump codehosting from every fdt deploy
[23:52] <poolie> that seems highly worthwhile
[23:52] <lifeless> no, it won't.
[23:52] <poolie> why?
[23:53] <lifeless> codehosting isn't in fdt anyhow, its a nodowntime-with-handholding deploy
[23:53] <lifeless> the handholding is because of 2
[23:53] <lifeless> solve the handholding problem and it can move to nodowntime
[23:54] <lifeless> the constraints are that we must be safe to delete the deploy directory after the deploy.
[23:54] <lifeless> well, there are probably more, but thats the key one I see.
[23:54] <poolie> what specifically is the problem
[23:54] <poolie> ok
[23:55] <lifeless> the problem today is that the nodowntime deploy pauses for hours because we can't interrupt bzr safely, so we wait until there are only a few clients connected then manually check that they are all CI servers and whatnot
[23:55] <lifeless> and then interrupt them ungracefully
[23:56] <lifeless> the deploy process is 'upgrade instance 1, upgrade instance 2' - serialised - which gets us no downtime
[23:56] <lifeless> during the deploy, the symlink for the active tree is updated, and after that we assume we can delete the tree at any point
[23:57] <lifeless> a few trees are kept around, but when we do multiple deploys in a day, there is no fixed window for when a tree will be deleted
[23:57] <poolie> sure
[23:58] <lifeless> we probably need to rejigger a few things, and having a quick-stop-listening step is fine with me as long as we don't set ourselves up for messy failures that we need to ignore / whatever.
[23:58] <poolie> so the handholding is that
[23:58] <poolie> they want to delete the tree when the processes using it have finished
[23:59] <poolie> however, that is always going to take a while, unless we're prepared to just abruptly kill connections


[12:22] <cmaloney> 1;2cmorning
[12:27] <jrwren> good morning.
[12:28] <cmaloney> how goes?
[12:33] <jrwren> not sure. Day is just getting started
[12:33] <jrwren> How goes with you?
[12:34] <jrwren> amazon is making a ringworld show. could be interesting
[12:39] <cmaloney> So far so good. Just woke up
[12:39] <jrwren> oh man... rpm is going to CRUSH deb at speed: http://rpm.org/wiki/Releases/4.14.0
[12:40] <cmaloney> partially because I have a "self-induced" headache and am making coffee
[12:40] <jrwren> self-induced? What did you do?
[12:41] <cmaloney> Port
[12:41] <cmaloney> ;)
[12:41] <jrwren> ooooh... wonderful!
[12:41] <jrwren> what kind?
[12:41] <cmaloney> Dow's Ruby
[12:42] <cmaloney> Nothing fancy, but still good
[12:42] <jrwren> yup, that is good.
[15:54] <brousch> If port weren't so expensive, I would probably be an alcoholic
[15:54] <cmaloney> heh
[15:54] <brousch> That's not an invitation to link me to cheap port
[15:55] <cmaloney> Meijer has it on sale this week
[15:55] <cmaloney> You're welcome
[15:55] <cmaloney> Also I think Trader Joe's has a decent port, but I haven't checked recently.
[15:56] <jrwren> i am an alcoholic, port is cheap enough.
[15:56] <jrwren> mix your own, buy some cheap brandy and some cheap red wine, mix unit you like it.  pour mans port
[15:57] <cmaloney> Even better: science until you get it right!
[15:57] <jrwren> art too.
[16:43] <jrwren> what is rick_h talking about? when things like what happen?
[17:04] <rick_h> jrwren: which one?
[17:06] <jrwren> "I'm always curious what work is done when things like this take place. What really drives the product decisions."
[17:06] <jrwren> that tweet was all alone in my feed.
[17:06] <jrwren> now I see it was follow up to your previous tweet, which twitter did not show me.
[17:29] <rick_h> jrwren: hah note Twitter fun
[17:29] <rick_h> And greg-g getting my back as I "wtf squarespace?!"
[17:31] <greg-g> :) :)