[05:03] <Kano> btw fuse 2.7.0 is in sid now. please update gutsy too
[06:35] <Hobbsee> ...how often does google send legit emails to people, vs all the jobspam from people who *arent* google?
[06:39] <crimsun> I don't believe I've ever received unsolicited email from Google.
[06:40] <Hobbsee> i more meant people pretending to be google, who actually arent
[06:40] <ajmitch> google will send *anyone* job spam
[06:40] <ajmitch> crimsun: that is rather surprising
[06:40] <Hobbsee> ajmitch: it's targeted.  ish.
[06:41] <ajmitch> Hobbsee: I know
[06:41] <Hobbsee> weird.
[06:45] <jdong> Hobbsee: good evening hobbsee. I am hajan, the deposed prince of nigeria.
[06:46] <jdong> Hobbsee: I need your help getting $60,000 out of the country. I'd like to deposit it in your bank account but first need you to wire me $100USD to ensure that it works.
[06:46] <TheMuso> heh
[06:46] <Hobbsee> jdong: hahaha
[06:46] <jdong> lol :)
[06:47] <Hobbsee> some woman in adelaide actually fell for that recently  30K
[06:47] <jdong> reading my spam folder is NOT a healthy habit :D
[06:47] <jdong> Hobbsee: that's NOTHING
[06:47] <jdong> Hobbsee: the US apparently records like $15million a year in money lost to the nigerian scams...
[06:47] <jdong> Hobbsee: that statistic amazes me
[06:47] <TheMuso> ouch
[06:47] <Hobbsee> jdong: yeah...but by one person?
[06:48] <jdong> and worst... it's probably those philanthropic older generation people who are falling for this stuff
[06:48] <jdong> Hobbsee: haha, not by one person :)
[06:49] <Hobbsee> yeah - that was by one person, which is why i was so surprised
[06:49] <jdong> Hobbsee: ouch that sucks... and once that money is gone, it's gone.
[06:50] <Hobbsee> exactly
[06:51] <jsgotangco> jdong: i've witnessed that too in a former workplace...never asked us before they proceeded
[07:21] <calc> Hobbsee: hi :)
[07:22] <Hobbsee> heya calc!
[07:22] <Hobbsee> calc: how's it going?
[07:22] <calc> Hobbsee: pretty well
[07:22] <Hobbsee> calc: is married life fun?
[07:22] <calc> Hobbsee: got married last saturday
[07:22] <Hobbsee> i know :
[07:22] <Hobbsee> * :)
[07:23] <calc> Hobbsee: ah ok
[07:23] <calc> Hobbsee: merging bits of ooo 2.3 so i can upload it eventually
[07:23] <TheMuso> calc: Yet you're not on your honeymoon
[07:23] <calc> TheMuso: no vacation time available yet
[07:23] <TheMuso> ah
[07:24] <Hobbsee> calc: ahhh
[07:24] <calc> we went off for the weekend, going on a cruise next year when i have some time available
[07:24] <TheMuso> Nice.
[07:24] <Hobbsee> yeah, working a new job probably isnt helpful for leave
[07:25] <ajmitch> calc: oh, congrats & all :)
[07:25] <calc> ajmitch: thanks :)
[07:26] <calc> hopefully rene doesn't get annoyed, heh
[07:26] <StevenK> calc: When is OO.o 2.4 due?
[07:26] <ajmitch> a debian developer, getting annoyed by ubuntu changes? never...
[07:26] <calc> StevenK: next spring
[07:26] <Hobbsee> StevenK: soon after he manages to get oo.o 2.3 built.
[07:27] <calc> StevenK: we are planning to just use 2.3.1 in ubuntu+1
[07:27] <StevenK> Heh
[07:27] <calc> so that the LTS doesn't have a potentially buggy version
[07:27] <calc> or at least less buggy than usual
[07:27] <StevenK> Ah, so 2.3 isn't a development release?
[07:27] <calc> no
[07:27] <calc> at least not that i know of
[07:28] <calc> i think 2.1 just got skipped due to the timing of releases
[07:28] <calc> 2.1 dec06 2.2 mar07
[07:29] <StevenK> Ah. They decided in December to bin 2.1 and aim for 2.2 in March
[07:29] <calc> 2.3 sep07 2.4 mar08 3.0 sep08
[07:30] <calc> StevenK: oh ok, didn't know about that
[07:30] <calc> so we will end up skipping 2.4
[07:30] <calc> gutsy 2.3.0 gutsy+1 2.3.1 gutsy+2 3.0 is what i am planning on so far
[07:30] <StevenK> calc: That was a guess, sorry
[07:33] <calc> StevenK: ah well i don't know anything about 2.1 other than that we skipped it for ubuntu afaik
[07:33] <calc> StevenK: so you know as much as me about that ;)
[07:35] <pitti> Good morning
[07:35] <Hobbsee> pitti!
[07:37] <Hobbsee> :)
[07:37] <StevenK> piMorning pitti!
[07:38] <pitti> hey StevenK
[07:38] <StevenK> pitti: Can you give back gabber on all arches again?
[07:38] <pitti> StevenK: done
[07:38] <StevenK> pitti: Thanks.
[07:39] <bryce> what does "give back" mean?
[07:40] <pitti> bryce: try again to build a package if it failed previously
[07:45] <StevenK> Hobbsee: RSN :-P
[07:46] <Hobbsee> StevenK: i hearby voluntell you to fix it.
[07:46] <StevenK> Hah
[07:47] <ajmitch> morning pitti
[07:47] <pitti> hey ajmitch
[07:49] <StevenK> pitti: Would you mind terribly running checkrdepends on drescher for libdb3{,-dev}?
[07:52] <pitti> StevenK: http://people.ubuntu.com/~pitti/tmp/db3-rdepends.txt
[07:52] <StevenK> pitti: Thanks!
[07:52] <pitti> StevenK: thanks to you!
[07:53] <StevenK> Hrm, no build depends on libdb3-dev.
[07:54] <StevenK> And a *whole* bunch of libdb3 rdepends. Enough that I don't really want to touch them, it being ~ 53 packages.
[07:56] <pitti> StevenK: a lot of those packages look like totally unrelated to libdb3
[07:56] <pitti> StevenK: it seems that the libtool disease is at fault here
[07:56] <StevenK> Yes.
[07:56] <pitti> (promoting dependencies to transitive dependencies)
[07:57] <pitti> I bet that a lot of packages won't depend on any libdb any more with -Wl,--as-needed
[07:57] <StevenK> Well, do we want to look at killing libdb3 completly for Gutsy?
[07:57] <pitti> StevenK: while it would be a nice target, I don't think that we should waste much developer time on it TBH
[07:57] <pitti> StevenK: it'll happen in Debian eventually anyway
[07:58] <pitti> and us doing the transition in Ubuntu won't even help Debian (much, at least)
[07:59] <StevenK> pitti: I was curious to see how much did depend on libdb3.
[07:59] <StevenK> Oh, gah
[08:01] <StevenK> gabber fails again.
[08:02] <pitti> bryce: requestsponsor> oh, I didn't touch that for a looong time
[08:03] <pitti> bryce: and in fact I should rewrite it to use proper attachments instead of pasting the diff into the description (LP allows this now)
[08:04] <bryce> pitti: ahh.  I thought it was new
[08:05] <pitti> bryce: replied to your mail with more details
[08:05] <bryce> cool
[08:06] <pitti> hi thekorn
[08:09] <thekorn> hi ptti
[09:09] <Hobbsee> guten morgen, mvo
[09:09] <mvo> hey Hobbsee
[09:09] <Hobbsee> mvo: :)
[09:10] <Hobbsee> mvo: well, in truth, i was going to say hello to you anyway, but that was too good an opportunity to give up.  do you want the number?
[09:13] <mvo> Hobbsee: if you have it at hand, but I remember what the issue was I think
[09:14] <Hobbsee> mvo: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/125928
[09:14] <ubotu> Launchpad bug 125928 in ubuntu-restricted-extras "Recommends in main "metapackages" get installed, but not universe "metapackages"" [Medium,Fix released] 
[09:14] <Hobbsee> ubotu isnt very smart, when it comes to the same bug effecting multiple products.
[09:15] <mvo> yep
[09:15] <mvo> thanks Hobbsee
[09:15] <Hobbsee> mvo: no problem.  thanks in advance for fixing.
[09:16] <desrt> mvo; too much preparation
[09:17] <desrt> mvo; tea isn't something you can think too much about.  it ruins it.  you just have to feel it.
[09:17] <Hobbsee> desrt!
[09:17] <pitti> Nafallo: bug 127836 approved
[09:17] <ubotu> Launchpad bug 127836 in bacula "[SRU]  bacula-director-pgsql not installable" [Medium,In progress]  https://launchpad.net/bugs/127836
[09:17] <pitti> desrt! *hug*
[09:17] <desrt> hello hobbsee, pitti
[09:17] <desrt> pitti; missed you at guadec :(
[09:24] <mvo> desrt: friendly-recovery got in :)
[09:24] <desrt> mvo; nice.  upstart glue yet?
[09:25] <mvo> desrt: haven't really checked, but it magically worked for me (installing the pkg was enough), so I guess yes
[09:25] <desrt> spiffy
[09:26] <mvo> some more plugins and i18n and it rocks the boat
[09:26] <desrt> ahh.. i18n
[09:26] <desrt> can you i18nify shellscript? :)
[09:26] <desrt> gettext(1).  nice.
[09:27] <mvo> I have never writen a POTFILE.in with shell in it, I'm curious :)
[09:28] <mvo> desrt: https://code.launchpad.net/~mvo/friendly-recovery/ubuntu (just fyi)
[09:28] <desrt> how bizarre....
[09:28] <desrt> (ha ha ha.  i crack me up.)
[09:28] <StevenK> desrt: Booo, hiss
[10:43] <Nafallo> pitti: thanks :-)
[10:54] <Tonio_> seb128: ping ?
[10:55] <seb128> Tonio_: pong
[10:55] <Tonio_> seb128: hi ;) sorry for bugging you but I have a little packaging question...
[10:55] <Tonio_> seb128: in a cdbs packaging how would you perform something before patches are applied ?
[10:56] <Tonio_> seb128: easy to perform a post-patches or makebuilddir thing, but nothing comes to my mind for "pre-patches" task
[10:56] <pitti> Tonio_: pre-build::
[10:56] <Tonio_> pitti: does that exist ?
[10:56] <pitti> Tonio_: yeah, see /usr/share/cdbs/1/rules/buildcore.mk
[10:56] <pitti> # This target is called before almost anything else happens.  It's a good place
[10:56] <pitti> # to do stuff like unpack extra source tarballs, apply patches, and stuff.
[10:56] <Tonio_> pitti: oki, cdbs doc misses infos on that point
[10:57] <seb128> Tonio_: what pitti said ;)
[10:57] <Tonio_> seb128: yeah, I was just lost since there is almost no doc on that point
[10:57] <seb128> just curious what do you need to do before applying the patches?
[10:57] <seb128> yeah, better to read the source with cdbs sometimes
[10:58] <Tonio_> seb128: in fact knetworkmanager was released without the famous admin/ dir
[10:59] <Tonio_> so mbiebl copies it from a kapptemplate builddep
[10:59] <Tonio_> seb128: the point is that he copies the files within post-patches
[10:59] <Tonio_> seb128: and we have to patch admin/ for rosetta :)
[10:59] <Tonio_> seb128: weird, I know, but that's what I have to in that very specific context..... the issue is btw upstream, they should provide that admin/ dir
[11:00] <seb128> Tonio_: I would just edit admin directly and get the changes in the diff.gz
[11:01] <siretart> asac: re bug #121439 with 'toggling' the rf-switch, we meen switch it off and on
[11:01] <ubotu> Launchpad bug 121439 in network-manager "[Gutsy] Network Manager Applet can't connect wireless with ipw3945 driver" [High,Incomplete]  https://launchpad.net/bugs/121439
[11:01] <Tonio_> seb128: I would have done that that way, but I want to stay sync with debian :)
[11:01] <seb128> right
[11:03] <asac> siretart: how?
[11:06] <siretart> asac: what do you mean with 'how'? by turning it on and off
[11:06] <siretart> asac: there is a little slider on the front of my notebook, I switch it to the left and then to the right
[11:10] <asac> ah ... ok
[11:10] <asac> nothing i can do then :)
[11:10] <asac> siretart: are you on feisty?
[11:11] <siretart> asac: no, I'm on gutsy
[11:14] <asac> siretart: can you summarize your behaviour? open-network doesn't work, while wpa does?
[11:14] <asac> siretart: sorry ... but the bug is pretty busted by lots of different symptoms claimed
[11:15] <siretart> asac: right
[11:15] <siretart> asac: there are in fact several bugs here
[11:15] <siretart> asac: let me explain how I connect to my home wifi
[11:16] <siretart> asac: NM tries to connect to my AP, it takes several secs. In this timeframe, I need to toggle the switch
[11:16] <siretart> asac: then I get a dialog presented to enter my password. I say cancel here
[11:16] <siretart> asac: then I try again to connect, this time it works, but disconnects after 0.5 seks
[11:17] <siretart> asac: then I select my home network a third time, then I have a connection
[11:17] <asac> siretart: wpa?
[11:17] <siretart> asac: and I can reproduce this behavior since about 3 weeks
[11:17] <siretart> asac: yes, this is a WPA2 secured network
[11:17] <asac> right ... lets try to figure this out
[11:17] <asac> siretart: ok
[11:17] <siretart> with open networks, I only get the 2nd bug
[11:17] <asac> can you post a log in pastebin?
[11:17] <siretart> which was reported seperately
[11:18] <Amaranth> dude i gave up on wpa2 and switched to WEP
[11:18] <asac> ok lets go for wpa first
[11:18] <Amaranth> figure no one here will be able to get in anyway and i didn't want to mess with wpa_supplicant
[11:18] <siretart> asac: the 2nd bug is pretty well described in #124706
[11:19] <siretart> bug #124706
[11:19] <ubotu> Launchpad bug 124706 in network-manager "NM sometimes drops connection before associating, logfile says assertion `dev != NULL' failed " [Undecided,New]  https://launchpad.net/bugs/124706
[11:19] <asac> siretart: you have a log for wpa?
[11:20] <siretart> yes, but its rather long, and I'd rather pass it to you privately via email
[11:21] <asac> siretart: for wpa: are you asked for passphrase?
[11:22] <asac> siretart: how long does it take until wpa_supplicant/nm gives up?
[11:22] <siretart> asac: I guess about 10 seconds
[11:23] <asac> does it fall back to wired then?
[11:23] <asac> siretart: ok ... can you see if wpa_supplicant tries ap_scan 2 ?
[11:23] <siretart> it doesn't fall back to wired, since there I have no wired connected
[11:23] <siretart> I sent you the log
[11:23] <asac> ok
[11:25] <siretart> asac: btw, network manager gives wpa_supplicant the AP_SCAN 1 command
[11:25] <asac> ok
[11:25] <asac> can you test without going offline in irc?
[11:26] <siretart> asac: I suspect I'm presented the dialog because wpa_supplicant didn't associate within some timeout, so nm assumes the key was wrong and asks for a new key. it would help if the dialog would indicate that
[11:26] <siretart> asac: I'm at work, and have no wireless here
[11:26] <asac> ok
[11:26] <asac> let me wait for the log
[11:27] <siretart> I sent it to asac@u.c
[11:27] <asac> yes
[11:27] <asac> now got it
[11:28] <siretart> asac: the log starts when I got home. The 131.188 ips are my 'universitary' ips, avahi does recognize at once that I'm now at home
[11:29] <siretart> asac: my home ips start with '192.168...'
[11:29] <asac> asisak: at first you got an ip?
[11:30] <asac> Jul 25 21:42:50 faui44a NetworkManager: <info>    address 192.168....
[11:30] <asac> ?
[11:30] <asisak> asac: I don't use n-m
[11:31] <asac> sorry siretart ^^
[11:31] <siretart> asac: that is step 3 I outlined above. yes
[11:32] <asac> siretart: i don't see that eth1 is torn down in logs
[11:32] <asac> siretart: looks like its still up with that ip
[11:32] <siretart> asac: the applet told me something else
[11:36] <asac> siretart: ok ... i think we have to test this by using wpa supplicant manually
[11:37] <siretart> asac: when I use wpasupplicant manually, everything works like expected
[11:37] <siretart> asac: I'm out for lunch now, I'll ping you when I'm back
[11:37] <asac> siretart: what do you mean by manually?
[11:37] <asac> config ?
[11:37] <asac> i mean by using wpa_cli
[11:37] <asac> and just inject the commands that nm sends to it
[11:54] <iwj> seb128: Are you about ?  Would you have time now to talk about my gtk+ problem ?
[11:55] <seb128> iwj: hey. Yes, I have. I asked you for details yesterday but you didn't reply (or I didn't read it) ;)
[11:55] <iwj> Yes, I didn't reply yet.
[11:55] <seb128> ok
[11:56] <iwj> So: this is for consistent-login-screen.  One thing I'm doing is having gdm prompt for user/pass and then when accepted, start a new X server with the session in it.
[11:56] <iwj> The original X server goes back to the login screen.
[11:57] <iwj> This all works fine so far except that the gdm greeter issues the gdm login prompt slave with an endless series of blank usernames and blank passwords.
[11:57] <iwj> This only happens _while the login X server is not current_.
[11:58] <iwj> That is, if you switch back to the original VC manually it all works fine.
[11:58] <iwj> I tore my hair out and added lots of debugging code and I think what is happening is that the switched-away-from X server doesn't generate the key up event for the return key.
[11:58] <iwj> And in the meantime gtk+ synthesises a whole bunch of autorepeats.
[12:00] <iwj> My questions are: is this plausible ?  And what would be the best way to deal with it ?
[12:01] <iwj> My debugging code shows a lot of   Jul 25 17:36:00 samual15 gdmgreeter[15083] : DEBUG: iwj KEY_PRESS 65293 (state=0x0)
[12:01] <iwj> which is what you see when return is pressed.
[12:03] <seb128> hum, so that happens when you press enter to validate the password?
[12:03] <seb128> the VT is switched and it keeps sending key pressed event on the username,password entry?
[12:04] <iwj> Yes.
[12:04] <iwj> Well, there is a continuous stream of these key pressed events.
[12:04] <iwj> I don't know for sure where they're coming from.
[12:05] <seb128> do you have a callback attached and to what signal?
[12:05] <Amaranth> couldn't you just wait for a key up event before doing the vt switch?
[12:06] <iwj> Amaranth: There are (at least) three processes involved.
[12:06] <iwj> The original code has firstly a callback attached to `activation' of the text entry field.
[12:06] <Amaranth> yay overdramatic security
[12:06] <iwj> No, just a complicated job best done in several pieces.
[12:07] <iwj> And secondly it has an event hook which does some massaging of incoming events, for example to map button 3 to button 1.
[12:07] <seb128> iwj: does your callback return TRUE to indicate that the event has been handled?
[12:07] <iwj> It's not my callback.
[12:07] <iwj> It was there to start with.
[12:07] <Amaranth> i thought TRUE meant 'pass through to another handler'
[12:08] <seb128> Amaranth: http://www.gtk.org/tutorial/x1812.html
[12:08] <iwj> I haven't changed the greeter (which is what's malfunctioning) at all.
[12:09] <seb128> hum, k
[12:09] <iwj> Well, I have now, because I've filled it full of printfs.  But apart from that :-).
[12:09] <mvo> iwj: when you recive the final newline, can you try "whilte gtk_events_pending() gtk_main_iteration(); "?
[12:09] <seb128> I don't know, it's possible that the key release event goes to the wrong screen
[12:09] <Amaranth> seb128: oh, pygtk must flip it
[12:09] <seb128> but that would be weird
[12:09] <Amaranth> or i've been in compiz and web stuff too long to remember :)
[12:10] <seb128> Amaranth: that would be a stange idea from them do that
[12:10] <iwj> seb128: Err, quite possibly but I think not because the repeating stops when I switch VC back.
[12:10] <iwj> I think the key up event is just delayed.
[12:10] <iwj> That is the key up X event.
[12:10] <iwj> Does gtk+ synthesize autorepeat itself ?
[12:10] <seb128> not sure what you can do out of waiting for the key release event before switching then
[12:11] <seb128> not that I know, no
[12:11] <cjwatson_> Amaranth: pygtk doesn't flip it. http://www.pygtk.org/pygtk2tutorial/sec-Events.html
[12:12] <seb128> Amaranth, mvo: will compiz work on the second X server?
[12:12] <Amaranth> seb128: not at all
[12:12] <mvo> no
[12:12] <iwj> Joy.  I straced the X server to see if it was generating these events and it's wedged.
[12:12] <Amaranth> not for a few more years, at least
[12:12] <mvo> and it will not in the near future from all I understand
[12:12] <seb128> iwj: you have started on it now but I don't think working on it is really useful
[12:12] <seb128> iwj: compiz will be on by default and only works on the first server
[12:13] <mvo> iwj: could you try that event-processing thing before switching? I'm curious if that helps
[12:13] <iwj> seb128: !
[12:13] <seb128> gdm is being rewritten upstream to use gobject
[12:13] <Amaranth> iwj: DRI is awesome, no?
[12:13] <iwj> What's gobject got to do with it ?
[12:13] <seb128> and fast user switching using consolekit (what FC7 did) works quite fine (don't have to enter a password twice, etc) ... you just have the flickering on VT switch
[12:14] <seb128> iwj: basically they rewritte most of the gdm internals
[12:14] <Amaranth> this is why i liked the Xgl/Xnest idea :)
[12:14] <iwj> seb128: Oh errm.
[12:14] <seb128> which means the modifications we do will need to be done again next cycle
[12:14] <iwj> Nice to discover this now :-/
[12:14] <Amaranth> seb128: afaik it's already done
[12:14] <seb128> they talked about it at GUADEC
[12:15] <iwj> Ah.
[12:15] <Amaranth> gdm3 branch in svn seemed quite complete
[12:15] <seb128> Amaranth: it's not planned for this cycle and I didn't know there was so much changes
[12:15] <Amaranth> from what i understood it already worked in some form
[12:15] <iwj> My changes to gdm are relatively small but if they're completely overhauling the innards (which need it!) then I'm at the very least working on the wrong branch.
[12:15] <Amaranth> probably not feature complete compared to gdm2 and such though
[12:16] <iwj> seb128: What's consolekit ?
[12:16] <Amaranth> iwj: session management stuff
[12:16] <seb128> iwj: apt-cache show consolekit
[12:16] <Amaranth> !info consolekit gutsy
[12:16] <ubotu> Package consolekit does not exist in gutsy
[12:16] <Amaranth> ack
[12:16] <iwj> seb128: And in gutsy+1 this will work with the then-prevailing gdm ?
[12:16] <seb128> Amaranth: I've synced it from Debian yesterday, might not be uptodate
[12:16] <iwj> Amaranth: universe
[12:17] <Amaranth> seb128: should find the slides :)
[12:17] <Amaranth> iwj: nah, ubotu is just slow to update (once a week or something)
[12:17] <seb128> iwj: well, using consolekit will work in gutsy, FC7 already uses it and the code landed to GNOME upstream, it solves the "having to enter several times your password" and other usuability issues
[12:17] <iwj> Right.
[12:17] <seb128> it doesn't solve the "flicker and it ugly"
[12:17] <iwj> The point of consistent-login-screen was to get rid of the hideous useability problems.
[12:17] <seb128> right
[12:18] <iwj> Not that I'm really keen on a dbus-based answer.
[12:18] <iwj> Cont pp.94 etc.
[12:18] <Amaranth> http://lists.freedesktop.org/archives/hal/2007-January/006996.html
[12:18] <seb128> I did point you to the fedora spec when we discussed xgl some weeks ago I think, that's basically that they implemented
[12:18] <seb128> I've seen it working at GUADEC, it works nicely
[12:18] <iwj> Implemented in the last few weeks ?
[12:19] <seb128> not to mention that the current Ubuntu spec way conflicts with compiz since compiz will no work on the second xorg server
[12:19] <iwj> Right.
[12:19] <seb128> iwj: for fedora 7, not sure for how long it's available, a few weeks now I think
[12:19] <Amaranth> fedora 7 came out in may, iirc
[12:20] <iwj> Do you reckon we should try to push consolekit into gutsy instead ?
[12:20] <Amaranth> that's when i started getting swamped with dupes of a crash for alacarte
[12:20] <iwj> I mean, gutsy main installed-by-default.
[12:20] <seb128> iwj: yes, I asked pitti to have a look yesterday
[12:20] <iwj> pitty: ^
[12:20] <seb128> to know if he consider it sane to use
[12:21] <pitti> I didn't look yet
[12:21] <iwj> Wait a moment, if consolekit does it with VC switching then how does it solve the `compiz on first server only' problem ?
[12:21] <iwj> pitti: OK, I can.
[12:21] <Amaranth> iwj: it doesn't
[12:21] <Amaranth> iwj: only Xgl solves that one
[12:21] <seb128> iwj: it doesn't, only the first user will have compiz
[12:21] <cjwatson> I can understand why you can only have compiz on *one* server
[12:21] <iwj> But doesn't it also do a VC switch between login screen and actual session ?
[12:22] <Amaranth> cjwatson: the first server to come up grabs the dri/drm lock for itself
[12:22] <cjwatson> why does it have to be the *first* one? assuming that gdm isn't using DRI that is
[12:22] <cjwatson> oh, it's at the server level? ok
[12:22] <seb128> iwj: it's pretty much the current way, the switching logic is better only
[12:22] <iwj> The current code in gdm is a bit of a mess.
[12:22] <seb128> iwj: I don't think gdm keeps using a VT, no
[12:22] <Amaranth> i suppose you could have a custom xorg.conf that disables DRI for the gdm server
[12:22] <iwj> seb128: Hmm.  Not sure I approve of the lack of trusted path but I don't want to swim upstream.
[12:23] <Amaranth> but then only the _second_ server will be able to use compiz, even if they actually use metacity or ratpoison
[12:23] <cjwatson> Amaranth: right, that would be no worse than the current situation though
[12:23] <Amaranth> cjwatson: sure
[12:24] <iwj> seb128: So since you're being a mine of information (thanks!) do you happen to know whether Xephyr is at all useful ?
[12:24] <StevenK> infinity: Ping, re: libnss-db
[12:24] <iwj> I mean, is it any good.
[12:24] <iwj> I tried it but it died and I didn't bother debugging it.
[12:24] <Amaranth> iwj: hey i think xephyr can do glx
[12:24] <iwj> Amaranth: That's why I'm asking :-).
[12:24] <Amaranth> with this new aiglx magic
[12:24] <seb128> iwj: dunno about it
[12:24] <iwj> seb128: OK.
[12:24] <infinity> StevenK: pongish.. I'll look at it later tonight, after I've done some lpia and random IS work.
[12:24] <Amaranth> i saw something on the xorg list about it yesterday
[12:25] <StevenK> infinity: Okay, cool
[12:25] <Amaranth> i know it can do Render, not sure about Composite
[12:26] <iwj> Amaranth: There shouldn't be any difficulty in principle.
[12:26] <iwj> The question is really code quality.
[12:26] <Amaranth> well, i think keithp wrote it
[12:26] <Amaranth> and everyone seems to think it's so great they pretend xnest doesn't exist anymore ;)
[12:31] <Amaranth> iwj: "Unlike Xnest it supports modern X extensions ( even if host server doesn't ) such as Composite, Damage, randr etc."
[12:32] <iwj> Oh, bloody hell.
[12:32] <iwj> Did I mess much ?
[12:33] <Amaranth> iwj: "Unlike Xnest it supports modern X extensions ( even if host server doesn't ) such as Composite, Damage, randr etc."
[12:33] <Amaranth> glx doesn't seem to work though :/
[12:33] <iwj> Hmm.
[12:35] <seb128> Amaranth: gdmflexiserver --xnest user xephyr now when available
[12:35] <seb128> I just tried, compiz doesn't start in it
[12:35] <seb128> "Checking for Xgl: not present."
[12:35] <cjwatson> compiz 1:0.5.1+git20070725-0ubuntu1 produces uninstallable binaries: * compiz (amd64 i386)
[12:35] <cjwatson> hmm, that can't be good
[12:36] <seb128> cjwatson: weird, I've this version installed
[12:36] <cjwatson> it's the CD health checks
[12:36] <seb128> ah
[12:37] <seb128> I depends on compiz-fusion-plugins-extra again
[12:37] <seb128> which is in universe
[12:37] <seb128> dholbach fixed it for tribe-3
[12:37] <cjwatson> has anyone done a MIR for that yet?
[12:37] <seb128> maybe he didn't commit to bzr?
[12:37] <cjwatson> I'd rather promote it if we need it than kill the dep
[12:37] <seb128> mvo: did you revert the change on purpose?
[12:37] <seb128> cjwatson: https://wiki.ubuntu.com/MainInclusionReportCompizFusionPluginsExtra
[12:39] <cjwatson> pitti,iwj: could somebody review the above?
[12:39] <mvo_> seb128: yes
[12:39] <pitti> yes, can do
[12:41] <iwj> pitti: You do that, I'll take a look at consolekit.
[12:41] <iwj> First I think I need a cup of tea.
[12:42] <pitti> iwj: ok, thanks
[12:42] <pitti> StevenK: still no build love?
[12:43] <pitti> iwj: I'll have a look at CK, too; such kind of software deserves may eyes
[12:43] <mvo_> seb128, pitti: hm, looking at this again we may not need it in main afterall, -extra was required for trailfocus, but we decided to not use trailfocus later
[12:43] <StevenK> pitti: Right. I've reproduced it locally, too.
[12:43] <StevenK> libtool: link: cannot find the library `/usr/lib/libdb3.la' or unhandled argument `/usr/lib/libdb3.la'
[12:43] <StevenK> Sure, I know exactly why you can't find it. But why are you even looking!?
[12:43] <iwj> pitti: Sure.
[12:43] <seb128> StevenK: grep "libdb3.la" /usr/lib/*.la
[12:43] <pitti> StevenK: ah :) "KILL ALL .la FILES! KILL'EM, KILL'EM!"
[12:43] <mvo_> seb128, pitti: crap, sorry. extrawm is required for stickiness of wndows
[12:43] <iwj> I was going to actually install it here and give it a run for its money.
[12:44] <mvo_> seb128, pitti: so we need it afterall
[12:44] <seb128> hum, lunch
[12:44] <seb128> good idea ;)
[12:44] <pitti> mvo_: looks easy enough
[12:49] <Amaranth> iwj: apparently glx in xephyr is a compile-time option
[12:49] <pitti> seb128: since last dist-upgrade, gdm doesn't load the default theme any more and complains about not finding  some debian/moreblue thing; instead I get the blue theme with the flower
[12:50] <iwj> Amaranth: Shouldn't we just enable it ?
[12:50] <seb128> pitti: please open a bug, I merged with Debian and that was not trivial (we had a different packaging for some cycle)
[12:50] <Amaranth> iwj: indeed
[12:50] <seb128> pitti: I made have made some mistakes
[12:51] <pitti> seb128: ok, I'll do that; thank you!
[12:51] <seb128> you're welcome
[12:51] <seb128> anyway, lunch time, be back later
[12:52] <Amaranth> iwj: if i can figure out how :)
[01:06] <StevenK> pitti: Right, -ldb-3 and /usr/lib/libdb3.la appear in both /usr/lib/libglade-gnome.la and /usr/lib/libgnomemm.la
[01:07] <StevenK> pitti: At this point I'd like to add "Bloody libtool!"
[01:07] <pitti> StevenK: evil :/
[01:07] <pitti> StevenK: yeah, I think those la files contribute a lot to the superfluous dependencies we have in Debian/Ubuntu
[01:07] <iwj> pitti: consolekit seems to like having a secret in your environment.
[01:07] <siretart> asac: by manually I mean by using /etc/network/interfaces, which also uses nothing else than wpa_cli to configure wpa_supplicant
[01:08] <iwj> I haven't figured out what the secret can be used for yet but I'm not sanguine.
[01:08] <StevenK> pitti: Re-upload gnomemm (whatever package it's in) and glade removing the .la files?
[01:08] <Amaranth> iwj: all it'll get you is a nice mute signal when the session changes
[01:08] <Amaranth> or some other sort of pause
[01:08] <pitti> StevenK: ywah
[01:09] <pitti> StevenK: s/w/e/
[01:09] <StevenK> Bloody libtool!
[01:09] <iwj> Amaranth: So why is it described as a secret then ?  That sounds harmless.
[01:09] <Amaranth> iwj: it's just a unique identifier
[01:10] <StevenK> pitti: Do you think I can move gnomemm and glade to cmake from autotools in Ubuntu changes? :-P
[01:10] <Amaranth> a way of figuring out what processes belong to what session
[01:10] <cjwatson> Amaranth: what could you do by pretending to belong to a different session?
[01:10] <Amaranth> cjwatson: like i said, get yourself paused somehow (or unpaused, i suppose)
[01:11] <cjwatson> what does "paused" mean in this context
[01:11] <cjwatson> ?
[01:11] <Amaranth> the idea is when you switch to another user either your sound will get muted or apps playing video/audio will get some sort of signal to pause their playback
[01:12] <pitti> StevenK: isn't it enough to just remove the .la from debian/*.install?
[01:12] <Amaranth> i don't think that part is actually implemented yet though
[01:12] <pitti> StevenK: I wouldn't worry about the packaging a lot
[01:13] <Amaranth> and i suppose if you got the kernel involved you could increase the priority for the current session (scheduling-wise) and then an app could hog your CPU changing it's cookie to match the current session
[01:13] <Amaranth> but as of right now another app faking it's in your session doesn't give it anything
[01:15] <iwj> I see.
[01:16] <StevenK> pitti: Apparently, libglade doesn't have any *.la files in the source
[01:16] <pitti> StevenK: they are generated during build
[01:17] <StevenK> Ah
[01:17] <StevenK> And no debian/*.install
[01:18] <iwj> Amaranth: Looking at the code I think you are probably right but it shouldn't be described as a secret.
[01:18] <StevenK> Ah ha, it uses dh_movefiles.
[01:18] <iwj> Indeed there's special code to check the calling uid in some cases.
[01:20] <StevenK> pitti:   * Stop the .la files being installed while I'm at it. If I find the libtool authors ...
[01:20] <Amaranth> iwj: yeah, secret is the wrong word, it's just a cookie
[01:20] <pitti> StevenK: heh
[01:28] <iwj> seb128: So this FC7 consolekit demo involved their new gdm ?
[01:36] <StevenK> C'mon gabber, you want to build sucessfully this time.
[01:36] <StevenK> Mainly because I'm sick of fixing things you Build-Depend on.
[01:47] <StevenK> Sigh. Looks like gnomemm needs fixing too.
[02:10] <geser> mvo_: as you seem to deal with compiz: is there a way to make emerald the default window decorator for me?
[02:28] <cjwatson> Riddell: kdesudo> note that ubiquity will need changed to use kdesudo rather than kdesu
[02:31] <Riddell> cjwatson: our kdesudo package currently does dpkg-divert to take over /usr/bin/kdesu
[02:31] <Riddell> I'm not convinced its the best approach but kdelibs seems to have "kdesu" hardcoded in various places
[02:31] <cjwatson> oh, it provides the same options?
[02:32] <Riddell> cjwatson: yes, we've been working on it so it now provides the exact same command line options as kdesu
[02:32] <Riddell> but without the excessive complexity and asking for passwords when it doesn't need it
[02:36] <geser> Hi Hobbsee
[02:36] <Hobbsee> :)
[02:36] <iwj> Riddell: diversion doesn't sound like too silly an idea then.
[02:37] <StevenK> pitti: New libglade and gnomemm uploaded. I've confirmed locally that fixing those two makes gabber actually build.
[02:37] <pitti> StevenK: you rock :)
[02:38] <pitti> StevenK: but really, once that's done, maybe just stop worrying about libdb3; it'll sort itself out eventually, and it's not actually prone to a lot of vulnerabilities and such
[02:38] <StevenK> pitti: I was planning on. :-)
[02:39] <StevenK> pitti: I was going to polish off libapache2-mod-auth-plain, and then upload libapache2-mod-auth-pam and libapache2-mod-auth-plain, which will drop yada main reverse Build-Depends to one.
[02:39] <Hobbsee> has someone managed to fix openoffice and friends breaking?
[02:39] <mvo_> geser: try setting /apps/desktop/gnome/applications/window_manager/default to emerlad
[02:40] <StevenK> pitti: None if infinity approves of my libnss-db repackaging. *hint*
[02:44] <Hobbsee> sorry, .ods
[02:44] <cjwatson> mvo_: have you had a chance to look at bug 71483? an acquaintance of mine was asking about it last night
[02:44] <ubotu> Launchpad bug 71483 in gxine "xine breaks dapper -> edgy dist-upgrade on xubuntu" [Medium,Confirmed]  https://launchpad.net/bugs/71483
[02:45] <mvo_> cjwatson: let me check
[02:45] <Hobbsee> mvo_: thankyou for the bugfix :)
[02:48] <seb128> Hobbsee: what breakage? the one which is likely due to GTK?
[02:48] <Hobbsee> seb128: whatever makes it not start.
[02:48] <Hobbsee> (process:10828): GLib-GObject-CRITICAL **: /build/buildd/glib2.0-2.13.7/gobject/gtype.c:2242: initialization assertion failed, use IA__g_type_init() prior to this function
[02:48] <Hobbsee> (process:10828): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
[02:48] <Hobbsee> (process:10828): Gdk-CRITICAL **: gdk_screen_get_font_options: assertion `GDK_IS_SCREEN (screen)' failed
[02:48] <Hobbsee> seb128: ^
[02:49] <seb128> iwj: no, the consolekit code is in the current gdm, the rewrital is likely coming next cycle
[02:49] <seb128> Hobbsee: not yet, ETOOMANYBUGS
[02:50] <seb128> Hobbsee: I've fixed the glib2.0 bug which was screwing sparc though ;)
[02:50] <StevenK> seb128: What about a mass giveback once it publishes?
[02:50] <Hobbsee> seb128: that's a start :)
[02:51] <Hobbsee> seb128: working spreadsheets would be nice too though - who runs a sparc anyway?  :P
[02:51] <seb128> StevenK: already done some hours ago the mass giveback
[02:51] <StevenK> seb128: Cool
[02:52] <StevenK> seb128: http://launchpadlibrarian.net/8571844/buildlog_ubuntu-gutsy-sparc.gnucash_2.0.5-1.1ubuntu1_FAILEDTOBUILD.txt.gz ; is that due to fallout?
[02:53] <iwj> seb128: Oh.  OK, I'll try to look where to turn it on then.
[02:53] <seb128> StevenK: "fallout"?
[02:54] <seb128> iwj: in gdm/debian/rules, change the --with-console-kit=no
[02:54] <StevenK> seb128: Something that failed to build earlier not getting published before the build of gnucash was attempted.
[02:54] <iwj> So I see.
[02:54] <seb128> StevenK: I think libgnomecanvas needs to be build before, maybe some other libs as well right
[02:55] <asisak> maybe libgsf, libgoffice (maybe not for gnucash but for other packages)
[02:55] <seb128> iwj: gnome-screensaver also have code to use consolekit, I think you don't need to rebuilt this one, it's using dbus at runtime
[02:56] <StevenK> seb128: Which built 2 hours ago, with gnucash being attempted 3 hours ago. Would you mind giving it back on sparc only, and we'll see if it copes now?
[02:56] <seb128> StevenK: I'm not buildd admin, ask pitti doko infinity
[02:56] <TheMuso> If anybody could be so kind as to review/upload a new espeak package, as reported in bug 128137, that would be great.
[02:56] <ubotu> Launchpad bug 128137 in espeak "Please upload new upstream release of espeak." [Undecided,New]  https://launchpad.net/bugs/128137
[02:56] <Mithrandir> StevenK: given-back
[02:56] <StevenK> Ah, right.
[02:56] <StevenK> Mithrandir: Thanks
[02:56] <seb128> or Mithrandir ;)
[02:56] <iwj> seb128: Ta.  I'll let you know how I get on.
[02:57] <seb128> iwj: np, thanks
[02:57] <StevenK> Mithrandir: Do you have a hilight on 'give back' or something? :-)
[02:57] <Mithrandir> StevenK: no, but I'm waiting for my slow mail server to get off its lazy backsiden
[02:57] <StevenK> Heh
[02:57] <StevenK> My slow mail server needs a good hard Ubuntu install.
[02:58] <StevenK> I wish I could do the same to my webserver, but it's an EV5.
[03:05] <Riddell> cjwatson: I've been playing with adding an edubuntu-desktop-kde seed inside the edubuntu seeds, but since it probably just wants to extend kubuntu-desktop I'm wondering if it might be better to do it within the kubuntu seeds and depend on kubuntu-desktop in the normal seed way
[03:05] <Riddell> cjwatson: http://kubuntu.org/~jriddell/tmp/edubuntu-seed.diff http://kubuntu.org/~jriddell/tmp/edubuntu-meta.debdiff
[03:06] <cjwatson> it's an awkward case because it's at the intersection of both
[03:07] <cjwatson> I think on balance though it's better to have it in the Edubuntu seeds because the CD images would be built as Edubuntu
[03:07] <cjwatson> depending on kubuntu-desktop there is interesting. Will that do the right thing with Recommends? I suspect possibly not
[03:08] <cjwatson> would be worth running germinate over that to test
[03:10] <Riddell> I don't plan on having any CD images, that's too much work
[03:10] <Riddell> package it makes looks like this http://paste.ubuntu-nl.org/31393/
[03:10] <Riddell> which doesn't look like the right thing for recommends
[03:12] <cjwatson> that looks OK, it Depends: kubuntu-desktop which Recommends: the rest and is in Section: metapackages
[03:12] <cjwatson> I was thinking more about what germinate would think for task generation though
[03:12] <cjwatson> but if the only goal is a metapackage then your solution should work
[03:13] <cjwatson> somewhere at the back of my mind is figuring out how to express relationships between seeds in different flavours of Ubuntu
[03:14] <cjwatson> I've been wondering whether it might be better just to merge all the seeds into one big branch and use subdirectories for flavour-specific seeds
[03:14] <cjwatson> then you could say edubuntu/desktop-kde: kubuntu/desktop
[03:15] <cjwatson> might be possible to speed up the archive's cron.daily by doing that, too, since it takes a while to run germinate at the end for all flavours and all architectures
[03:15] <cjwatson> and would save some of the seed merging work we have to do
[03:15] <cjwatson> but would make it harder to view edubuntu/desktop as a branch of ubuntu/desktop
[03:16] <Riddell> how would I find out what germinate does to the tasks?
[03:16] <cjwatson> run germinate on your seeds (see its man page), and look at the resulting 'desktop-kde' file
[03:16] <cjwatson> you'll want to run it in a scratch subdirectory
[03:16] <cjwatson> it spits everything out to the cwd
[03:26] <iwj> seb128: Well, it doesn't seem to work perfectly for me.
[03:26] <iwj> It's a bit tricky because I seem to have some other problem with this machine.
[03:26] <seb128> iwj: what doesn't work correctly?
[03:27] <iwj> I managed to get it to get stuck on a black screen just by switching back and forth between two users.
[03:27] <iwj> I'm going to try to reproduce it.
[03:29] <iwj> Now I can't even get a prompt logout dialogue.
[03:32] <Riddell> cjwatson: seems sane to me http://kubuntu.org/~jriddell/tmp/edubuntu-germinate/desktop-kde
[03:33] <cjwatson> Riddell: right, that's missing recommends - you'll note it e.g. doesn't include bluez-utils
[03:33] <cjwatson> missing transient recommends from kubuntu-desktop, I mean
[03:33] <cjwatson> in practice it'll probably be OK as long as you don't need tasks, it's just something to note
[03:33] <Riddell> right
[03:34] <cjwatson> maybe a workaround would be to have germinate honour recommends from section: metapackages
[03:34] <Riddell> ogra's at ubuntu live isn't he?
[03:34] <cjwatson> rather a hack though ...
[03:34] <Riddell> wonder if I should check it with him first before committing, or commit before he has a chance to complain :)
[03:35] <cjwatson> I think your diff earlier forgot to make edubuntu supported inherit from desktop-kde
[03:35] <cjwatson> (makes a difference to anastacia et al)
[03:35] <Riddell> right, I'll add that
[03:38] <Hobbsee> mvo_: assuming you know, but compiz still falls over with kde, even with your change.
[03:39] <Hobbsee> mvo_: oh wait, i think i still need to run compiz --replace
[03:39] <thom> mvo_: still hiding from me? :-)
[03:40] <cjwatson> Riddell: http://people.ubuntu.com/~cjwatson/tmp/germinate.recommends.diff - untested patch to make germinate follow recommends in section: metapackages
[03:44] <Riddell> cjwatson: seems to work http://kubuntu.org/~jriddell/tmp/edubuntu-germinate/desktop-kde
[03:45] <cjwatson> Riddell: rock on untested patches
[03:46] <cjwatson> that's a big deb size, probably wouldn't fit on a CD anyway ...
[03:55] <cjwatson> would anyone cry too much if lithium (i.e. CD image builds) went down for upgrade this weekend?
[03:55] <cjwatson> cdimage.u.c/releases.u.c will still be available
[03:56] <Hobbsee> cjwatson: absolutely :P
[03:56] <cjwatson> absolutely cry, or absolutely upgrade? :P
[03:57] <Hobbsee> cjwatson: the former.
[03:57] <Hobbsee> cjwatson: but either works :P
[03:57] <pitti> mvo_: got a minute?
[03:57] <Riddell> no tears here
[03:58] <Mithrandir> cjwatson: would work for me.
[03:58] <pitti> np for me
[04:01] <pitti> mvo_: can you please look at bug 123062? python-apt oddity
[04:01] <ubotu> Launchpad bug 123062 in apport "apport-gtk crashed with AssertionError in __setitem__()" [Undecided,Incomplete]  https://launchpad.net/bugs/123062
[04:09] <mvo_> thom: yes :P (but I'm back home so the pile gets smaller)
[04:09] <mvo_> pitti: looking, but I may require the sources.list for this
[04:10] <thom> mvo_: heh, no worries :)
[04:10] <lool> doko: It's Aurlien Jarno, not Aurelian :)
[04:11] <doko> lool: thanks, will fix it
[04:12] <pitti> mvo_: I hope you don't actually need deb-src lines to determine the source package?
[04:22] <geser> is there a way to use compiz with emerald without having to start emerald by hand?
[04:25] <seb128> geser: not sure, you can hack gnome-wm as a workaround
[04:27] <mvo_> geser: try setting /apps/desktop/gnome/applications/window_manager/default to emerlad
[04:28] <geser> the current value of that key is compiz, does compiz still start when I change that?
[04:29] <cjwatson> would somebody in ubuntu-main-sponsors please unsubscribe ubuntu-main-sponsors from bug 119572? reason's given in the bug
[04:29] <ubotu> Launchpad bug 119572 in iso-codes "wrong English names in iso-codes (dup-of: 124657)" [Medium,Confirmed]  https://launchpad.net/bugs/119572
[04:29] <ubotu> Launchpad bug 124657 in iso-codes "Candidate Revision for iso-codes_1.0a-1ubuntu1" [Undecided,New]  https://launchpad.net/bugs/124657
[04:29] <cjwatson> I was about to do it but realised I'm not in the team
[04:30] <cjwatson> er, yeah, the latter bug
[04:30] <geser> mvo_: I tried setting /apps/compiz/plugins/decoration/allscreens/options/command to emerald, but the description mentions that it's only used when no decorator is running an the compiz wrapper starts gtk-window-decorator
[04:33] <geser> mvo_: btw does gnome-compiz-manager still work with compiz fusion? I'm currently using compizconfig-settings-manager to configure compiz as gnome-compiz-manager didn't work on my last test
[04:35] <StevenK> cjwatson: Unsubscribed
[04:36] <StevenK> cjwatson: I'm sure if you asked pitti nicely, he'd add you to ubuntu-main-sponsors. :-P
[04:36] <keescook> I snagged it.  :)
[04:36] <cjwatson> StevenK: I just requested joining, in fact
[04:36] <cjwatson> (pitti's membership of ubuntu-main-sponsors is deactivated ...)
[04:37] <keescook> cjwatson: I've approved you.
[04:37] <cjwatson> keescook: thanks!
[04:37] <keescook> no problemo!  :)
[04:37] <StevenK> Ah, keescook, dholbach and seb128 are admins
[04:37] <pitti> hey keescook
[04:37] <StevenK> I thought of pitti because he approved me when I joined
[04:37] <keescook> hiya pitti
[04:38] <mvo_> geser: hm, I'm afraid there is currently no easy way to set emerald, that needs to be fixed
[04:39] <mvo_> geser: I think gnome-compiz-manager would need a update at least (haven't checked though)
[04:39] <geser> keescook: Hi, is bug #124725 still in your work queue?
[04:39] <ubotu> Launchpad bug 124725 in fireflier "[CVE-2007-2837]  Unsafe tmp file handling" [Undecided,Confirmed]  https://launchpad.net/bugs/124725
[04:39] <keescook> say, cjwatson, I'd like to chat about the apparmor bits -- what was added to the seeds?  If we're forcing the apparmor module to load in an install, it will block (future) selinux stuff.  I'd like to avoid that.
[04:39] <keescook> geser: it is, yes.  let me go comment on it.
[04:39] <geser> mvo_: should I file a bug about the emerald thing?
[04:40] <geser> mvo_: do we really need two programs to configure compiz?
[04:40] <StevenK> geser: It's only that the other four aren't packaged yet.
[04:40] <geser> StevenK: there exists 6 programs already to configure compiz?
[04:40] <pitti> keescook: apparmor-utils is standard Recommends: now, i. e. installed by default (with apparmor as dependency)
[04:41] <StevenK> geser: Joke.
[04:41] <StevenK> But probably.
[04:41] <ubotu> Launchpad bug 119796 in openbox "please sync openbox 3.4.2-1 from Debian unstable (main)" [Wishlist,Confirmed]  https://launchpad.net/bugs/119796
[04:41] <seb128> pitti, keescook: should I do something about bug #128159? There is a CVE number mentioned
[04:41] <ubotu> Launchpad bug 128159 in gaim "Jabber: Client and OS version visible to authorized buddies" [Undecided,New]  https://launchpad.net/bugs/128159
[04:41] <cjwatson> does it list both main and universe sponsoring requests?
[04:41] <keescook> pitti: so people wanting selinux will be able to uninstall apparmor (since it's not a depend)?
[04:41] <cjwatson> ah, yes, apparently so
[04:42] <cjwatson> oh well, as long as my browser never visits https://bugs.launchpad.net/~ubuntu-universe-sponsors, I can see which is which from the visited-link colour at the right
[04:42] <keescook> seb128: I'm on the fence about OS version disclosure.  pitti, do you have an opinion about it?
[04:42] <pitti> keescook: right
[04:42] <keescook> geser: look good; I will get it spun up.  :)
[04:42] <seb128> keescook: I'm surprised it got a CVE
[04:43] <pitti> keescook: I have no context; a server discloses OS version?
[04:43] <seb128> Ng: there is tens of crashing bugs about it
[04:43] <pitti> keescook: doesn't nmap detect this, too, nowadays?
[04:43] <keescook> pitti: no, the gaim client responds with detailed version info to a query.
[04:43] <seb128> pitti: you can get OS informations from random contacts (no need to have been accepted in their buddy lists)
[04:44] <Ng> seb128: yeah. weirdly I didn't get any apport stuff about it
[04:44] <keescook> pitti: yeah, there are many way to detect such things, but usually with less precision.
[04:44] <pitti> seb128: you mean gaim sends out that information to anybody? getting them from other clients is hardly a vuln
[04:44] <seb128> pitti: yes, if I add you to my jabber list and look to your informations I'll know what version of pidgin you run and that you use linux
[04:45] <pitti> seb128: you know that anyway :-P
[04:45] <seb128> ;)
[04:45] <pitti> seb128: joke aside, I'm not terribly scared by it
[04:45] <seb128> me neither
[04:46] <seb128> I'm even surprised it's considered as a security issue
[04:46] <seb128> but it got a CVE number apparently so I was wondering what to do with the bug
[04:46] <keescook> seb128: they'll assigned CVEs for anything.  ;)
[04:46] <pitti> seb128: it's not a security issue itself, it is just helpful with exploiting them
[04:46] <seb128> right
[04:47] <pitti> keescook: so they slowly move towards 'assign a name to every issue and let the vendors decide'?
[04:47] <Mithrandir> does anybody know what http://err.no/tmp/weird-icon.png is?  (The leftmost).  It doesn't have a tooltip and disappears if I click on it.
[04:48] <soren> Mithrandir: It's the icon that shows up when the icon the app is trying to show is missing :)
[04:48] <soren> Mithrandir: So guessing what app is putting it there will be.. Well, a guess. :)
[04:48] <pitti> Mithrandir: it's the "no icon" icon
[04:49] <pitti> Mithrandir: i. e. you added something to your toolbar and then uninstalled the package that belongs to it (together with the real icon)
[04:49] <Mithrandir> that's helpful, especially with the missing tooltip.
[04:49] <ion_> Yay for a compiz-compatible emerald in gutsy. 
[04:49] <Mithrandir> it's the notification area, so that'd be quite spectacular.
[04:49] <pitti> Mithrandir: oh, hm; I was just going to search where gnome saves its custom starters, but that won't help then
[04:50] <seb128> pitti: .gnome2/panel2.d/default/launchers FYI (in case you need it for something else)
[04:50] <pitti> seb128: thanks
[04:50] <soren> Mithrandir: You can try "xwininfo -tree" and click on the panel and see if there's anything that rings a bell.
[04:51] <soren> Mithrandir: Well.. At least you could have before it disappeared :)
[04:51] <seb128> Mithrandir: does it happen at every startup?
[04:51] <iwj> seb128: So consolekit definitely doesn't work properly (but also I have some problem with the sound on this machine).
[04:52] <Mithrandir> seb128: afaik, yes.
[04:52] <keescook> geser: eww, debian/changelog is a symlink to changelog -- it's confusing diff
[04:52] <keescook> (or rather, patch)
[04:52] <seb128> Mithrandir: maybe remove /usr/share/icons/hicolor/icon-theme.cache (and maybe the one for the theme you use and gnome also) and restart
[04:52] <asac> calc: managed to setup your laptop for testing (with stable wired net) already?
[04:52] <seb128> Mithrandir: might be a program which install an icon but didn't update the cache
[04:53] <calc> asac: not yet, we have a meeting in about 5min though
[04:53] <asac> calc: i know ;)
[04:54] <calc> asac: i can set it up after the meeting
[04:54] <asac> calc: i really need you ;) ... you have ipw which appears to be broken for quite some time
[04:54] <calc> asac: yea its quite odd
[04:55] <calc> asac: it seemed to work at the sprint when i booted off cd from what i recall, but didn't before or after at home
[04:55] <asac> calc: lets do it after meeting :) ... at least getting started.
[04:55] <calc> asac: ok
[04:59] <pitti> keescook: #ubuntu-meeting
[04:59] <pitti> tkamppeter: hi
[05:00] <pitti> tkamppeter: I'm so glad to have finally fixed that cups fd leakage *phew*
[05:01] <tkamppeter> pitti, did you also fix something with DBUS there or only with the authentication SUID program?
[05:01] <calc> btw intel q6600 is now ~ $270 for anyone looking for a new system
[05:01] <pitti> tkamppeter: libdbus only; the auth helper has always been fine
[05:02] <tkamppeter> So for everyone the problem was in libdbus?
[05:02] <pitti> tkamppeter: for many at least, and it is very unlikely that the other reporters had this for a different reasons
[05:02] <StevenK> calc: I would, considering the US dollar is so crap at the moment. :-P
[05:03] <tkamppeter> pitti, then I think next is to make HAL calling the hal-cups-utils script to set up print queues.
[05:04] <pitti> tkamppeter: right
[05:07] <geser> keescook: can bug #124629 be closed for edgy and feisty? packages.u.c lists the security packages already
[05:07] <ubotu> Launchpad bug 124629 in gsambad "[CVE-2007-2838]  Unsafe tmp file usage" [Undecided,Fix committed]  https://launchpad.net/bugs/124629
[05:08] <seb128> bryce, Mithrandir: xorg-server with the clipping patch uploaded
[05:09] <bryce> seb128: excellent, thanks
[05:09] <seb128> you're welcome, I didn't do much, just tested and uploaded ;)
[05:10] <keescook> geser: ah, yes.  good catch; thanks.
[05:54] <geser> can an ubuntu-main-sponsor look at bug #126641 and ACK it (if it's OK)?
[05:54] <ubotu> Launchpad bug 126641 in apache2 "sync apache2 (2.2.4-2) debian sid main" [Unknown,Fix released]  https://launchpad.net/bugs/126641
[05:54] <pitti> geser: oh, that's just one new debian revision, should be easy
[05:54] <pitti> geser: I'll have a look tomorrow at my archive day; please subscribe u-archive
[05:55] <geser> done
[05:55] <geser> and thanks
[05:55] <pitti> geser: thanks to you
[05:56] <Hobbsee> pitti: i hope you learn to clone yourself around tribe 5 :)
[05:56] <pitti> Hobbsee: prohibited in .de, sorry :)
[05:56] <Hobbsee> pitti: haha
[05:56] <Hobbsee> pitti: or just stop sleeping
[05:57] <pitti> Hobbsee: my gf already allowed me taking the laptop on honeymoon, but not for working :)
[05:57] <tkamppeter> pitti, I have e-mailed you my cupsd.conf. See the second of my two e-mails.
[05:57] <Hobbsee> pitti: oh dear.  you should leave the laptop at *home* for such events.
[06:02] <geser> Hobbsee: creating a second pitti will take at least 9 months and some years till he can work on Ubuntu :)
[06:02] <cjwatson> (and didn't particularly want it, either)
[06:02] <Hobbsee> i'd hope not :P
[06:03] <Hobbsee> geser: hmmm.  darn
[06:18] <ScottK> keescook and bryce: I just read the scrollback in #ubuntu-meeting.  That was me that bounced the inkscape backport bug.  IMO, given the backports charter, I shouldn't be backporting stuff as a way to get around an SRU.
[06:19] <keescook> ScottK: cool by me; it's a bit of a confusing process.  :)
[06:19] <ScottK> Agreed (about confusing)
[06:19] <ScottK> I recently got added to ubuntu-backporters and I'm trying to be more rigorous about it than has historically been the case.
[06:20] <bdmurray> Hobbsee: my clones are almost ready to start working
[06:20] <Hobbsee> bdmurray: yay!
[06:20] <Hobbsee> bdmurray: they can do kde's bugs :P
[06:21] <bdmurray> edubuntu might be more appropriate ;)
[06:21] <Hobbsee> awww
[06:21] <bryce> ScottK: ah that's great to hear.  Yes, when I started I found SRUs and backports to be very mysterious, perplexing processes
[06:21] <Hobbsee> sru's are still a very mysterious, perplexing black art
[06:22] <ll-cool-jdong> sru's are black art indeed :)
[06:22] <mathiaz> keescook: did you get a chance to look at my apparmor branch ?
[06:23] <keescook> mathiaz: not the new one yet; still doing OSCON things.  however, kyle talked with Novell, and seems happy to carry the newer kernel module; so I think we'll be able to merge to a newer release -- I want to get a specific revision number from novell for the branch before finalizing it.
[06:23] <bryce> scottk, so it's great to have you tending to the backports :-)  Some time I would like to chat with you about backports for X drivers.
[06:23] <ScottK> bryce: Just convince me it's not scary and I'm all yours.
[06:23] <bryce> there are many requests for backporting drivers, and it would be nice if we had a smooth accepted process on both ends for handling them
[06:23] <mathiaz> keescook: ok. I've started to package libaalogparse
[06:23] <keescook> great!  :)
[06:24] <mathiaz> keescook: the library to parse apparmor audit messages.
[06:24] <mathiaz> keescook: I've already updated my branch with the first shot.
[06:24] <mathiaz> keescook: so if you want to merge my branch you shouldn't take the last revision
[06:24] <keescook> mathiaz: great; is this related to auditd bits too?
[06:25] <ll-cool-jdong> bryce: is this about the Xorg intel drivers, or fglrx?
[06:25] <mathiaz> keescook: you should take version 492
[06:25] <mathiaz> keescook: everything is written in the changelog anyway.
[06:25] <keescook> mathiaz: okay, I'll do that and get it started now.  :)
[06:25] <bryce> ll-cool-jdong: it's a general issue across all drivers, but the two of present interest are -nv and -intel
[06:26] <mathiaz> keescook: libaalogparse could be used with auditd.
[06:26] <mathiaz> keescook: at least that's one of the goal from upstream.
[06:26] <ll-cool-jdong> bryce: both ScottK  and I don't have much knowledge about X, so we are very very reluctant to just flip the build dependencies and ASSUME everything will work under earlier versions of Xorg
[06:26] <mathiaz> keescook: for now, I want to use libaalogparse with apport
[06:26] <bryce> the issue is that support for new hardware is often only available in the latest versions of drivers, so after a release (feisty) has been out a while, we start getting users who have difficulty getting things working
[06:26] <keescook> cool; okay, I'm headed back to OSCON now -- gotta finish up some demos for my "ubuntu security" talk.  :)
[06:27] <mathiaz> keescook: to be able to include apparmor audit messages in apport report.
[06:27] <mathiaz> keescook: ok. Thanks for the review.
[06:27] <ll-cool-jdong> bryce: if you can either test building the packages with build dep modified yourself, or get some X developer around here to tell us it's a reasonable thing to try, then we'd be more than willing to attempt a backport
[06:27] <bryce> ll-cool-jdong: understood.  This is why I'd like to discuss with you guys about processes and so on - what info do you need, what work should be done to prepare, testing to be done, etc.
[06:27] <ll-cool-jdong> bryce: furthermore backporting X drivers tends to have more regressions than other types of backports, and we don't have the mass of people to test them
[06:28] <ll-cool-jdong> bryce: so basically, at this point, I'd like a Ubuntu developer who is familiar with X to tell me "I'm reasonably confident that backporting xorg-driver-whatever by forcing it to build against Feisty X.org will result in a driver at least as functional as feisty's"
[06:29] <ScottK> bryce: Just to give you an idea, this is what I'm currently working on to get clamav 0.9x backported for Dapper: https://wiki.ubuntu.com/MOTU/Clamav
[06:29] <ll-cool-jdong> bryce: either that, or around the order of 20 different testers to tell me that soame thing
[06:29] <ScottK> bryce: And said developers says "And if I break it, I'll fix it" would help a lot too.
[06:30] <ll-cool-jdong> yeah, that too
[06:30] <bryce> ll-cool-jdong: good to know.  Yes, I've been having people test the -nv and -intel drivers (which I've built for Feisty for them to test).  So good to hear that having a lengthy testing period is key in the process
[06:30] <ll-cool-jdong> as it stands now, if a driver backport ends up knocking out 10% of the driver users.... ScottK and I would be clueless as to what to do
[06:30] <poolie> what sound server is gutsy meant to be using?
[06:31] <poolie> esound, or polypaudio or something else?
[06:31] <poolie> hi jdong
[06:31] <StevenK> Hrm. Where did Launchpad go?
[06:31] <ll-cool-jdong> hi poolie :)
[06:31] <ll-cool-jdong> poolie: and the cool people call the latter "pulseaudio" nowadays
[06:32] <Hobbsee> StevenK: i ate it
[06:32] <ll-cool-jdong> poolie: apparently the american colonoscopy society complained or something ;-)
[06:32] <StevenK> Fair enough. Just so I know.
[06:32] <poolie> heh
[06:34] <seb128> doko: http://launchpadlibrarian.net/8327874/Stacktrace.txt looks like a ld lookup issue, no?
[06:39] <bryce> keescook: re- the xorg-server sync with debian, I have it on my todo list to review their changes and update the package.  I did xorg yesterday (it's ready to go after I've run some tests on it), and I hope to get xinit and libx11 done as they haven't had a sync in a while.  Then xorg-server after that.
[06:39] <seb128> doko: and why do you think a crash in /usr/lib/gconv/UTF-16.so is a libgnomevfs bug?
[06:40] <bryce> and hopefully I can squeeze in another round of driver updates sufficiently before the freeze.
[06:46] <lool> iwj: I met a lot with gdm folks, Brian Caemron and William John McCann in particular, and I did build a relatively clear idea that the path to reach the ConsoleKit based gdm is still long; basically, the mccann-gobject branch is still very rough
[06:47] <lool> iwj: mccann did a bunch of other changes such as a new configuration system which is to be integrate with a yet to be released dconf at some point, there's no real support for themes (and of course no compatibility), and many more issues
[06:47] <doko> seb128: or a followup error, same with the second one. just the crash doesn't help me much. and the reports don't say anything what was done to rule out a bug in libgnomevfs
[06:47] <lool> iwj: For example the transitions between VTs are expected to work seemlessly without any hardware resolution switch like currently
[06:48] <lool> iwj: And instantaneously, especially if you want some animation to get you from the login VT to the session VT
[06:48] <geser> Mithrandir: can you please give-back haskell-http? thanks
[06:48] <iwj> lool: Right, but what's the situation in gdm2 ?
[06:48] <lool> iwj: So all in all, you can expect this to take a lot of time to be functional, and I even suggested this might need to be a separate module
[06:49] <lool> iwj: I think at some point gdm2 will move into a "no new feature" mode and keep the support for legacy things
[06:49] <seb128> lool: hum?
[06:49] <iwj> If consolekit isn't supposed to work with fast user switching in gdm2 then ... err ...
[06:49] <seb128> lool: FC7 already uses consolekit and fast user switching, no?
[06:49] <iwj> The gdm2 source already has a --with-console-kit option.
[06:49] <Mithrandir> geser: given-back
[06:49] <lool> iwj: While discussions at the gdm maintenance meeting were really nice, there were some major issues with the merge plans as Sun relies on plenty of complex features which may not work anymore in the consolekit branch
[06:50] <seb128> lool: it's a "gobject" branch, not a "consolekit" one, isn't it?
[06:50] <lool> seb128: I don't know what FC has; perhaps it's consolekit enabled, but I don't know what version mccann pushed there
[06:50] <lool> seb128: There's a separate pure consolekit branch?
[06:50] <seb128> lool: 2.19 has consolekit support and same for gnomescreensaver
[06:50] <lool> Ohhhh
[06:50] <seb128> lool: I don't think so, you are the one mentionning it
[06:50] <lool> Then we're not talking of the same thing at all
[06:51] <seb128> lool: there is a gobject branch
[06:51] <lool> seb128: I thought consolekit was a pure mccann-gobject thing, but it's not
[06:51] <seb128> no, it's not
[06:51] <seb128> it's what FC7 uses for user switching
[06:51] <lool> Ok, so sorry for dragging irrelevant issues to the discussions
[06:52] <seb128> that's alright ;)
[06:52] <iwj> seb128: This gnome-screensaver consolekit support - is it supposed to be in our 2.19.1.1 ?
[06:52] <lool> iwj: In short then, I think the gdm2 branch and all its features are worthwhile, but the high level features such as power management, screen saver, input methods, nm applet and the like will be 100x times easier to integrate in the next major gdm branch
[06:52] <seb128> iwj: I think so
[06:53] <iwj> grep says no but it may be called something else ...
[06:53] <seb128> lool: in fact gdm 2.18 already has the consolekit configure option
[06:53] <lool> iwj: So it's better to not develop new major features at this point, but fixes to gdm2 are very worthwhile
[06:53] <seb128> iwj: src/gs-listener-dbus.c:gs_listener_update_console_kit_idle (GSListener *listener)
[06:53] <iwj> Oh, sorry, I can't spell `console'.
[06:53] <asac> calc: there?
[06:54] <iwj> OK, I'll go back to trying to find out why it's not working.
[06:54] <iwj> Starting with how it's supposed to work ...
[06:55] <lool> seb128: You recall that discussion on ugly backtraces we had?
[06:55] <lool> seb128: There's some discussion on the topic in the OpenSuse BT https://bugzilla.novell.com/show_bug.cgi?id=258433
[06:55] <ubotu> Novell bug 258433 in Kernel "gdb reports "Failed to read a valid object file image from memory." when debugging" [Major,New] 
[06:55] <seb128> lool: yes
[06:56] <lool> seb128: I tried that vdso thing (don't do it live!), and the backtraces truly changed
[06:56] <seb128> lool: ah, the "Failed to read a valid object file image from memory"
[06:56] <seb128> lool: that's https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/74691
[06:56] <ubotu> Launchpad bug 74691 in linux-source-2.6.20 "Unable to debug under 2.6.22 on i386: Failed to read a valid object file image from memory" [High,Fix released] 
[06:56] <seb128> lool: thanks for the information
[06:57] <lool> seb128: But the backtraces remain quite ugly nevertheless :)
[06:57] <lool> seb128: This is a before / after http://bugzilla.gnome.org/show_bug.cgi?id=460513
[06:57] <seb128> lool: still not good :/
[06:59] <calc> asac: yea
[06:59] <calc> asac: sorry i was in another irc client discussing ooo
[06:59] <calc> asac: i'll go set up my laptop now
[07:01] <asac> calc: cool
[07:01] <asac> calc: i will have to go to supermarket in a few minutes ... will be away for 30 minutes or so
[07:02] <calc> asac: ok that works good for me, about to eat lunch
[07:02] <calc> asac: ping me when you get back
[07:02] <asac> calc: fine
[07:36] <geser> mvo_: are you planing to update compizconfig-settings-manager soon? it's missing a depends on python-gtk2
[07:37] <mvo_> geser: not soon, but feel free to branch from our compiz repository in launchpad and fix it there. I will be happy to merge. otherwise, please remind me tomorrow (or file a bug) I need to leave now
[07:53] <EtienneG> hey guys, did anybody know what happened with libapache-mod-security in feisty ?  Did it got deprecated, or rolled into another package ?
[07:55] <Mithrandir> EtienneG: RoM; undistributable for legal reasons
[07:55] <Mithrandir> from removals.txt in debian
[07:56] <EtienneG> Mithrandir, thanks a lot
[07:59] <calc> asac: should we have wireless-tools pre22 synced from debian?
[07:59] <calc> asac: er merged (seems there are some ubuntu changes)
[08:02] <asac> calc: lets first test
[08:02] <asac> let me create notes for you case
[08:03] <asac> what info do you have about your chipset?
[08:08] <calc> asac: 945 chipset with 3945 wireless
[08:08] <calc> hmm let me move the laptop over near my desktop
[08:09] <calc> then i don't have to worry about the network going down, heh
[08:11] <calc> ok i found a table to stick it on
[08:12] <calc> table in this case is a stool, heh
[08:12] <calc> it lists the chipset as 945GM/GMS/940GML
[08:12] <calc> wireless 3945ABG
[08:12] <calc> rev 02
[08:20] <geser> has someone an explanation for this build failure http://launchpadlibrarian.net/7726938/buildlog_ubuntu-gutsy-i386.steam_2.2.31-4.1_FAILEDTOBUILD.txt.gz ?
[08:20] <geser> dpatch deapply-all
[08:20] <geser> set: 8: Illegal option -o pipefail
[08:21] <elmo> geser: dash is /bin/sh ?
[08:21] <iwj> t
[08:22] <calc> asac: ping
[08:23] <cjwatson> dpatch here is #! /bin/bash
[08:23] <cjwatson> -rwxr-xr-x 1 root root 29702 2007-06-11 23:46 /usr/bin/dpatch
[08:23] <cjwatson> that build log is Last-Modified: Mon, 21 May 2007 16:40:30 GMT
[08:24] <cjwatson> see dpatch 2.0.25 changelog
[08:24] <cjwatson> geser: a give-back should do the trick
[08:24] <Mithrandir> given-back
[08:25] <geser> thanks
[08:25] <asac> calc: ok
[08:28] <calc> asac: what should we test next?
[08:28] <asac> calc: so ... open network doesn't work for you?
[08:29] <calc> asac: no
[08:29] <calc> asac: it does work but only in the wireless-* interfaces file case or dhclient eth1 case
[08:30] <calc> and it sort of works with wpa-driver ipw
[08:30] <calc> but it gives ioctl errors
[08:30] <asac> calc: can you also post your iwconfig --version ?
[08:30] <calc> wext (using wireless extensions) it never gets an ip
[08:30] <calc> ok
[08:30] <asac> for the record
[08:30] <calc> note its only up to 21 and the driver is 22
[08:30] <calc> but yea i'll post it up
[08:31] <geser> and what's the build problem in http://launchpadlibrarian.net/8577358/buildlog_ubuntu-gutsy-i386.apache2_2.2.4-2_FAILEDTOBUILD.txt.gz ?
[08:31] <calc> that combined with the other findings is why i think going to new debian version might fix it
[08:31] <geser> it fails nearly at the end with objcopy: debian/apache2-dbg/usr/lib/debug/usr/sbin/apache2-mpm-worker: Invalid operation
[08:31] <asac> calc: yes i know
[08:32] <asac> calc: anyway ... please post :)
[08:32] <calc> ok logged into launchpad about to add it to the bug
[08:33] <calc> done
[08:33] <calc> hmm it only recommends v16 or later, hmm
[08:34] <asac> you have bug id?
[08:34] <calc> bug 128360
[08:34] <ubotu> Launchpad bug 128360 in network-manager "nm fails to connect to open network" [Undecided,New]  https://launchpad.net/bugs/128360
[08:37] <asac> ok i think that wpa-XX will not succeed to connect to open network
[08:38] <asac> so what happens if you remove every option from that wireless card?
[08:38] <asac> in interfaces
[08:38] <calc> asac: its already removed except for the default boot stuff
[08:38] <calc> asac: i am doing this from the tribe-3 live cd
[08:39] <calc> for the open ap if i use wireless-ssid foo it works
[08:39] <asac> calc: ok
[08:39] <calc> because it bypasses wpasupplicant entirely (and wireless-tools too maybe?)
[08:39] <asac> pleaes ifdown that interface now
[08:39] <calc> ok
[08:39] <calc> done
[08:39] <asac> then stop network-manager
[08:39] <calc> asac: how do i stop it normally i have done it before by stopping dbus
[08:40] <asac> not you won't have net can you still type here?
[08:40] <calc> i am typing to you from my desktop
[08:40] <calc> my laptop is right next to it
[08:40] <calc> so dropping network on the laptop is fine
[08:40] <asac> /etc/dbus-1/event.d/25NetworkManager stop
[08:40] <calc> ok
[08:40] <calc> done
[08:40] <asac> ifconfig eth1 up
[08:40] <asac> (if eth1 is your device)
[08:41] <asac> then open a terminal and start wpasupplicant like:
[08:42] <asac> wpa_supplicant -g /var/run/wpa_supplicant.global -dd 2>&1 | tee /tmp/wpa.debug.log
[08:42] <asac> does that block and print ... starting?
[08:42] <asac> (all this as root)
[08:43] <calc> sits there and i see nothing
[08:43] <asac> not even a start message?
[08:43] <asac> in the beginning?
[08:43] <asac> ok
[08:43] <asac> nevermind
[08:43] <calc> yea nothing at all printed
[08:43] <asac> now open a second terminal
[08:43] <calc> its sitting there though
[08:44] <calc> grr i missed supplicant.global
[08:44] <asac> start like i said please
[08:44] <calc> ok i did it exactly spelled right this time, but still no message printed
[08:44] <asac> thats ok then
[08:44] <asac> ok
[08:45] <calc> what should i do in the second window?
[08:46] <asac> wpa_cli -g/var/run/wpa_supplicant.global add_interface eth1 "" "" wext
[08:46] <asac> i think
[08:47] <calc> ok i'll try that
[08:47] <asac> does that succeed?
[08:47] <calc> should there be a space after -g?
[08:47] <asac> calc: sorry
[08:47] <asac> wrong
[08:48] <asac> just use wpa_cli -g/var/run/wpa_supplicant.global add_interface eth1 "" "" /var/run/wpa_supplicant.run
[08:48] <asac> the idea is that driver is automagically detected
[08:48] <calc> unknown command add_interface
[08:49] <calc> "Unknown command 'add_interface'" to be exact
[08:49] <asac> try -p instead of -g
[08:49] <calc> "Failed to connect to wpa_supplicant - wpa_ctrl_open: Not a directory"
[08:50] <_wattazoum_> Hello
[08:50] <calc> asac: do i need a -i before eth1?
[08:51] <calc> asac: oh i noticed interface is in the manpage but not add_interface, not sure if that is the issue
[08:51] <asac> no
[08:52] <asac> wait a second
[08:52] <asac> the -i comes later
[08:52] <asac> we first have to initialize the supplicant
[08:52] <calc> ok
[08:53] <asac> calc: ok its interface_add :)
[08:53] <calc> ok with -g that worked
[08:53] <calc> it printed some stuff out
[08:54] <asac> ok ... now you should see something going on in wpa_supplicant terminal, right?
[08:54] <calc> it printed a bit and then stopped printing out more
[08:54] <asac> find ... next start wpa_cli terminal just like
[08:54] <calc> about one screen worth (at 1280x800)
[08:54] <asac> wpa_cli -ieth1
[08:55] <asac> that should bring you to a shell where you can type help
[08:55] <calc> says could not connect to wpa_supplicant
[08:55] <calc> do i need -g/path again?
[08:55] <asac> no
[08:55] <asac> interface is added
[08:55] <calc> ok
[08:55] <asac> so -ieth1 should work
[08:55] <calc> last thing it shows is "Could not connect to wpa_supplicant - re-trying"
[08:56] <calc> and its just sitting there
[08:56] <asac> please post what supplicant said
[08:56] <calc> ok
[08:56] <asac> when you added_interface
[08:58] <asac> calc: did the interface_add succeed?
[08:58] <asac> maybe restart supplicant
[08:58] <asac> then do it again
[08:58] <calc> not sure if it did
[08:58] <asac> please redo and look what it prints
[08:58] <calc> i'll post up the output so you can see what it did
[08:58] <calc> ok i'll retry it
[08:58] <asac> no
[08:58] <asac> please retry
[08:58] <asac> it should be obvious
[08:58] <asac> either it says:
[08:58] <asac> FAIL
[08:58] <asac> or OK
[08:58] <asac> or Command timed out
[08:59] <asac> e.g. the wpa_cli ... interface_add command i mean
[08:59] <calc> FAIL
[08:59] <asac> restarted supplicant?
[08:59] <calc> it looks like it hung on add ealier
[08:59] <calc> restarting it now
[08:59] <asac> yes
[08:59] <asac> restart it
[08:59] <asac> then try the command
[09:00] <calc> still can't do connect with wpa_cli -ieth1
[09:00] <calc> s/do//
[09:00] <asac> hey
[09:00] <asac> did it OK
[09:00] <asac> ?
[09:00] <calc> yea it ok'd
[09:00] <calc> it appears to hang during trying to get current scan results first without requesting
[09:00] <calc> i'll post the log file for you to see
[09:00] <asac> k
[09:01] <calc> wow it didn't even print the full message out the second time
[09:01] <calc> i'll explain once i have it posted
[09:02] <calc> ok its posted
[09:02] <calc> where it says:
[09:02] <calc> Trying to get current scan results first without requesting a new scan to speed up initial association
[09:02] <calc> the second time it didn't print anything past requesting...
[09:03] <bigredradio> Anyone here know if "Landscape" is OpenSource? Curious if this is a semi-fork of webmin.
[09:04] <asac> calc: ok
[09:04] <asac> lets give supplicant more hints
[09:04] <asac> please stop things
[09:04] <asac> start supplicant
[09:04] <asac> wait a bit
[09:05] <dsas> bigredradio: unlikely, webmin isn't included in ubuntu repos at all.
[09:06] <asac> calc: please start supplicant like before ... wait a bit
[09:06] <asac> then use
[09:06] <asac> wpa_cli -g/var/run/wpa_supplicant-global interface_add wlan0 \ "" wext /var/run/wpa_supplicant
[09:06] <asac> aeh s/\\//
[09:06] <asac> and use the right global filename
[09:07] <asac> instead of wlan eth1
[09:07] <asac> of course
[09:07] <calc> ok
[09:08] <calc> so wpa_cli -g/var/run/wpa_supplicant.global interface_add eth1 \\ "" wext /var/run/wpa_supplicant.run
[09:08] <asac> no :=
[09:08] <asac> remove the \\
[09:08] <calc> oh ok
[09:08] <asac> it was a line break here in file :)
[09:09] <asac> ah
[09:09] <asac> and remove the .run
[09:09] <asac> interestingly it worked better that way here
[09:09] <asac> (e.g. less fail)
[09:09] <calc> ok
[09:09] <calc> got further
[09:09] <calc> want me to do -ieth1 now?
[09:09] <asac> yeah
[09:09] <calc> ok it worked
[09:10] <asac> wow
[09:10] <asac> please stop everything again
[09:10] <asac> and try again with wext -> ""
[09:10] <asac> it should work
[09:10] <asac> its probably the .run
[09:10] <asac> :)
[09:10] <calc> looks bad
[09:10] <calc> hmm nm
[09:10] <asac> wait a bit
[09:11] <calc> it got to command prompt with -ieth1
[09:11] <asac> great
[09:11] <asac> so its the .run :)
[09:11] <asac> funny thing
[09:11] <asac> ok
[09:11] <asac> so what does scan_results
[09:11] <asac> give you
[09:11] <asac> (at the prompt)
[09:11] <calc> i see vinther
[09:11] <asac> ok list_networks ?
[09:11] <calc> i don't see the wpa access point but thats probably ok?
[09:11] <calc> vinther is the open ap
[09:11] <asac> maybe its ok
[09:12] <asac> we haven't scanned yet
[09:12] <calc> no networks listed in list_networks
[09:12] <asac> ok
[09:12] <asac> then lets get started
[09:12] <calc> ah ok vinther might be from what was set on the card already
[09:12] <asac> first lets reproduce that it doesn't work the way network manager does it
[09:12] <calc> ok
[09:12] <asac> ap_scan 1
[09:12] <calc> OK
[09:12] <asac> (all now at wpa_cli prompt)
[09:12] <calc> yea
[09:13] <asac> add_network
[09:13] <calc> 0
[09:13] <asac> good
[09:13] <asac> SET_NETWORK 0 ssid "vinther"
[09:13] <asac> if thats the name
[09:13] <calc> OK
[09:13] <asac> SET_NETWORK 0 key_mgmt NONE
[09:14] <calc> OK
[09:14] <asac> enable_network 0
[09:14] <asac> ... then you should rumbling things in wpa_supplicant
[09:14] <calc> OK
[09:14] <asac> and get some output at prompt
[09:14] <calc> yea
[09:14] <asac> what happens?
[09:14] <asac> does it loop?
[09:14] <calc> trying to associate...
[09:15] <asac> e.g. does it look like it repeats things
[09:15] <calc> authen with...
[09:15] <calc> yea it loops
[09:15] <calc> authentication times out
[09:15] <asac> does it name the ap it tries to associate with?
[09:15] <calc> oh
[09:15] <calc> it says Authentication with 00:00:00.... timed out.
[09:15] <shaya> did someone break gtk? :)
[09:15] <calc> not with the hex of the router
[09:15] <asac> calc: yeah ok
[09:15] <asac> calc: disable_network 0
[09:15] <asac> to stop this garbage
[09:16] <shaya> just updated and acroread dies w/ a (acroread:7713): Gtk-CRITICAL **: gtk_rc_get_style: assertion `GTK_IS_WIDGET (widget)' failed
[09:16] <asac> then ap_scan 2
[09:16] <asac> and enable_network 0 again
[09:16] <calc> yes it says (SSID='vinther' freq=2437 MHz)
[09:16] <calc> OK
[09:17] <calc> shaya: i hear there were issues with ooo as well so probably so
[09:17] <calc> shaya: talk to seb128
[09:17] <calc> shaya: btw good to see you again, haven't noticed you around in years :)
[09:17] <seb128> shaya: looks like that's a GTK bug, there is bugs about it, dunno what's causing it though
[09:18] <shaya> phd'ing
[09:18] <calc> asac: still getting time outs
[09:18] <calc> asac: but without the ssid/freq
[09:18] <calc> asac: and it seems to take longer to time out now
[09:18] <seb128> shaya: it's on my list of things to look at, didn't start on it yet though
[09:18] <shaya> still maintain a single debian package :)
[09:18] <asac> calc: hmm
[09:18] <asac> calc: what do you see in scan_results ?
[09:18] <asac> maybe run scan
[09:18] <shaya> seb128: do you happen to have the old feisty packages somewhere?
[09:18] <asac> before
[09:18] <shaya> are they in launchpad?
[09:18] <calc> (hex) 2437 201 vinther
[09:19] <seb128> shaya: launchpad has all the binaries
[09:19] <seb128> shaya: you can download 2.11.5 from gusty
[09:19] <calc> after scan i see (hex) 2437 202 vinther
[09:20] <seb128> shaya: https://launchpad.net/ubuntu/+source/gtk+2.0/2.11.5-1ubuntu1/+build/355090
[09:20] <seb128> shaya: the left column has the binaries
[09:20] <seb128> (if you use i386 architecture)
[09:20] <calc> asac: see above ^
[09:20] <asac> calc: ok
[09:20] <asac> do you have an ap id?
[09:20] <asac> at hand?
[09:20] <calc> the hex code?
[09:21] <calc> 00:14:bf:2a:5f:e1
[09:21] <calc> it shows up in the scan_results
[09:21] <asac> yes
[09:21] <asac> ok
[09:22] <asac> set_network 0 bssid "00:14:bf:2a:5f:e1"
[09:22] <calc> do i need to disable_network first?
[09:22] <asac> you can ... not required though
[09:23] <calc> FAIL
[09:23] <calc> ah it was the quotes
[09:23] <asac> without "
[09:23] <asac> ?
[09:23] <calc> it worked after stripping
[09:23] <shaya> danke
[09:24] <asac> ok
[09:24] <calc> asac: still timed out
[09:24] <asac> ap_scan 0
[09:25] <asac> then disable_network 0
[09:25] <asac> and enable_network 0 again
[09:26] <calc> i see wpa_driver_wext_set_drop_unencrypted in the logs that doesn't cause a problem does it (no idea what it does)
[09:27] <calc> still timing out though
[09:27] <asac> actually i am really unsure if you can connect to open network using supplicant at all
[09:27] <asac> when i tried supplicant refused to do that saying that without encryption is not supported
[09:27] <calc> however feisty is setup i can connect to the open ap using NM
[09:27] <asac> yes
[09:27] <asac> but probably not using supplicant
[09:28] <calc> ah it knows not to try to connect using supplicant then?
[09:28] <calc> i have a wpa aes router i can try connecting to as well if you want
[09:29] <asac> i think your bug is that it tries to connect using supplicant
[09:29] <asac> it should work though the same way we did when you have wpa
[09:29] <calc> well when i try connecting to the wpa router it didn't work either last time i tried it
[09:30] <asac> right ... but that can be ap_scan
[09:30] <asac> ipw needs manual scanning ... and ap_scan 1 is automatic afaik
[09:30] <asac> do you have the wpa net up?
[09:31] <calc> yes
[09:31] <calc> its next to the laptop right now, so strong signal too :)
[09:31] <asac> ok ... but you didn't see it in scan results?
[09:31] <asac> scan_results
[09:31] <asac> in wpa_cli
[09:31] <calc> i don't see it in the scan results for some reason
[09:31] <asac> do you see it with
[09:32] <asac> iwlist eth1 scan ?
[09:32] <asac> (as root)
[09:32] <calc> hmm no
[09:32] <asac> hidden network?
[09:32] <asac> please make it visible for now
[09:33] <calc> no it is set to broadcast
[09:33] <calc> i can reboot and verify if i can see it in feisty if you want
[09:33] <calc> the ap can see the vinther ap, but can't see the laptop mac
[09:34] <asac> wierd
[09:34] <calc> that might be normal if the laptop isn't connected to anything though, not really sure
[09:34] <asac> maybe scan is better when you stop supplicant?
[09:34] <asac> iwlist scan?
[09:34] <asac> calc: no ... lets go and see if latest wireless tools help for that
[09:35] <asac> or ... please test feisty as well
[09:35] <asac> calc: maybe set your ap to TKIP (not AES) ?
[09:35] <calc> ok it still doesn't work i'll reboot into feisty quick and then we can test new wireless tools as well
[09:36] <calc> hold on this is weird
[09:36] <calc> i'm going to reboot the router
[09:36] <calc> it says its not secured
[09:36] <calc> i don't know if it got disabled at some point or the router is odd
[09:36] <asac> router crashed most likely
[09:38] <calc> ok i'm alive now
[09:38] <asac> you see it?
[09:38] <asac> in gutsy?
[09:39] <calc> still don't see it in gutsy i rebooted the router it shows security is disabled right now
[09:39] <calc> which is interesting
[09:39] <asac> how can you look at the router?
[09:39] <calc> i just log into it from my desktop
[09:39] <calc> i'm rebooting into feisty to see what i can see
[09:39] <asac> desktop == wired?
[09:39] <calc> yes
[09:40] <calc> does wpa_supplicant work with wpa2?
[09:40] <asac> yes
[09:40] <asac> depends on driver though
[09:40] <asac> but should
[09:40] <asac> at least detect
[09:40] <asac> i guess your router is broken
[09:40] <calc> ok
[09:40] <asac> :)
[09:40] <calc> i'll see how it goes in feisty
[09:40] <calc> it still had my password saved maybe i disabled security when i was testing it before going to the sprint
[09:41] <asac> ok
[09:41] <asac> enable security ... then scan for it
[09:41] <asac> with iwlist
[09:41] <asac> then with wpa_supplicant :)
[09:42] <calc> after turning on security in gutsy iwlist eth1 scan still didn't see it
[09:43] <calc> ok it sees both in feisty
[09:43] <calc> lets see if it can connect to both
[09:44] <calc> can connect to both on feisty
[09:44] <calc> hey
[09:44] <kwah> hi all. is there a policy somewhere about treating BUGs marked as wishlist? For example, is it allowed/necessary to mark duplicates?
[09:44] <calc> it only shows vinther on iwlist eth1 scan though
[09:44] <asac> calc: thats really strange
[09:44] <asac> calc: ok go back to gutsy then
[09:44] <asac> calc: we should be able to connect using wpa_supplicant
[09:45] <calc> correction it only shows the one i am connected to
[09:45] <asac> maybe save the daemon.log
[09:45] <asac> calc:
[09:45] <asac> you have to run as root
[09:45] <calc> after i connected to "calc" the other one it showed that one but only that one
[09:45] <asac> sudo iwlist scan
[09:45] <asac> otherwise it will just dump the cache
[09:45] <calc> oh ok, sorry i forgot to do that earlier
[09:45] <asac> yeah
[09:45] <asac> reboot please
[09:45] <asac> gutsy is more important ;)
[09:46] <calc> rebooting now
[09:46] <asac> good
[09:46] <asac> calc: at best just upgrade :)
[09:46] <asac> i feel scared about live-cd thing
[09:46] <calc> heh
[09:46] <calc> live cd usually works
[09:46] <calc> except when the fs is broken apparently
[09:47] <asac> yeah ... but its creeping slow and it might not be the latest
[09:47] <calc> yea
[09:48] <asac> anyway ... just reboot and lets see
[09:48] <calc> almost up now
[09:49] <calc> i'm going to retry NM for the WPA2 network
[09:49] <asac> yes do it
[09:49] <asac> capture log et al as well
[09:51] <calc> ok iwlist eth1 scan works for both
[09:52] <calc> doesn't appear to be connecting to the wpa2 network, or takes a long time to do it
[09:52] <asac> ok ... you should post both a feisty ... and a gutsy log
[09:52] <asac> to a new bug
[09:52] <calc> ok once it dies i will post the logs
[09:52] <asac> ipwXXXX cannot connect to wpa2
[09:52] <asac> good
[09:53] <asac> feisty (successful) ones are important as well
[09:53] <calc> er it connected but doesn't know it has
[09:53] <asac> why do you think you connected?
[09:53] <calc> no green dots but ifconfig has an ip
[09:54] <calc> and NM is still swirling
[09:54] <calc> it took about 2m to get an address which seems a bit long
[09:54] <calc> but it worked
[09:55] <calc> i think it might have taken a while because it popped up a window that got lost behind my full screen console window
[09:57] <calc> it worked after trying a second time
[09:57] <calc> and it shows it is connected
[09:57] <calc> trying to connect to the open ap now
[09:57] <calc> what the hell
[09:57] <calc> it connected to the open ap now too
[09:57] <calc> i am going to power cycle the box and try this again
[09:57] <asac> hehe
[09:57] <asac> i think your vinther ap is just broken
[09:58] <asac> just through it in the bin :)
[09:58] <asac> throw
[09:58] <calc> well it could be something changed when i connected to the wpa2 network first
[09:58] <wwoods> hey dudes - I'm working on getting some apport-related kernel patches upstream. Who should be CCd on these mails, beyond pitti?
[09:58] <asac> i don't know
[09:58] <asac> its probably live-cd related
[09:59] <calc> asac: i had issues before when trying on an installed version of gutsy
[09:59] <asac> its known to create arbitrary garbage at random places :)
[09:59] <asac> calc: when was that?
[09:59] <calc> asac: tribe-2 timeframe before sprint
[10:00] <asac> i can't tell
[10:00] <calc> next test i will do is try connecting to open ap, if it fails, connect to wpa2 if succeed attempt to connect to open ap again
[10:00] <asac> i wish i had such a wireless chipset to test
[10:00] <asac> ok
[10:00] <asac> try
[10:00] <calc> which is roughly what i did before this reboot, but i wasn't paying close attention to what i was doing
[10:02] <calc> asac: if the live cd creates random garbage is it safe to install using it either?
[10:02] <asac> no idea :)
[10:02] <calc> heh
[10:02] <asac> i would use alternate
[10:03] <calc> uh
[10:04] <calc> it looks like it is trying to use wpasupplicant to connect to the open ap
[10:04] <calc> didn't we determine it shouldn't be doing that?
[10:05] <asac> dunno .. did it do that when it succeeded?
[10:05] <calc> not sure, maybe
[10:05] <calc> its not getting an ip yet this time
[10:05] <asac> yeah ... would be nice to know
[10:05] <asac> we already know that it does try that when you didn't go wpa first
[10:05] <asac> try wpa2
[10:05] <asac> then open?
[10:06] <gnilor> can i ask what version of mac80211 subsystem is in the ubuntu packages? i hear people with .20 kernels ... it would help people wanting to try iwlwifi (ipw3945 and 4965) ?
[10:06] <calc> ok it failed the first attempt on open ap
[10:06] <calc> now trying wpa2 one
[10:07] <calc> it asked for the password twice
[10:08] <calc> 3 times now
[10:08] <calc> it seemed to ask a lot before but i wasn't sure if i was just messing up
[10:08] <calc> 4 times now
[10:09] <calc> 5 times
[10:09] <calc> ok i think i am going to consider this not working
[10:09] <calc> its up 6 times now and not connected
[10:10] <geser> Mithrandir: please give-back lhapdf on amd64. thanks
[10:10] <calc> guess what
[10:10] <calc> i tried the open ap after that and it connected
[10:11] <calc> i'm going to try the wpa2 one again
[10:13] <Mithrandir> geser: given-back
[10:13] <calc> asac: after a lot of attempts it finally connected to the secured one this time
[10:14] <calc> asac: got an updated wireless-tools to test out? ;)
[10:14] <asac> calc: did you do anything special?
[10:14] <asac> calc: or did it just succeed at some point?
[10:14] <calc> whoa when it finally connected NM applet went away
[10:14] <calc> its not in the bar anymore
[10:14] <calc> if you want this long log i can put it up on the bug report as well
[10:15] <calc> not sure if anything in it is useful
[10:16] <calc> the log shows that NM crashed at roughly the time it connected
[10:16] <asac> calc: it crashed
[10:16] <asac> start it with
[10:16] <asac> nm-applet --sm-disable
[10:16] <asac> from command-line
[10:16] <asac> :)
[10:16] <asac> yeah ... nm-applet has problems
[10:17] <calc> it looks like it is running at the command line but nothing in the bar
[10:17] <asac> hmm
[10:17] <asac> is NetworkManager still running?
[10:17] <calc> no
[10:17] <calc> that would be why... heh
[10:18] <asac> yes
[10:18] <asac> so NetworkManager crashed as well?
[10:18] <calc> i guess that is the crash i saw in daemon.log then
[10:18] <calc> apparently so
[10:18] <asac> ouch
[10:19] <asac> but understandable ... NetworkManager has probably lots of places where it uses not instantiated variables
[10:19] <asac> i already found 2
[10:19] <asac> by coincident
[10:19] <asac> you can start it through /etc/dbus*/eve*/25Netwo* restart
[10:22] <calc> yea it worked
[10:22] <calc> now it shows like its trying to reconnect to vinther
[10:22] <calc> (open ap)
[10:22] <calc> already have an ip though
[10:26] <calc> asac: what would the next step be?
[10:26] <calc> asac: i can get it to work but it is very unreliable
[10:26] <asac> is the ip still usable?
[10:27] <asac> calc i would like to do the same we did before
[10:27] <calc> it went away finally
[10:27] <asac> e.g. using wpa_supplicant only ... to see if that is already instable
[10:27] <asac> or if its network manager which makes the whole build shake
[10:27] <calc> the interface is up but no ip
[10:27] <asac> ok ... stop nm
[10:27] <asac> /etc/dbus*/eve*/25Netwo* stop
[10:27] <calc> done
[10:28] <calc> want me to start up wpa_supplicant like before?
[10:28] <asac> yes ... first be sure that eth1 is down
[10:28] <asac> the ifconfig it manually up
[10:28] <asac> so its in clean state
[10:28] <asac> look at iwconfig
[10:28] <asac> and iwlist
[10:28] <asac> if everything looks good
[10:29] <calc> its set to vinther in iwconfig
[10:29] <calc> iwlist can see both networks
[10:29] <johnnybuoy> hi all!
[10:30] <asac> calc: ok
[10:30] <asac> that should be ok then
[10:30] <calc> should i kill avahi as well
[10:30] <asac> start wpa_supplicant like before ... with tee to a log et al
[10:30] <asac> hmm
[10:30] <calc> it brought eth0 back up by itself
[10:30] <johnnybuoy> I'm creating a .deb file, and I need to change the PATH environment variable of the system. I was wondering how this is done/what the accepted way of doing this is
[10:30] <asac> calc: yes eth0 is not a problem
[10:30] <asac> eth1 ?
[10:30] <calc> didn't seem to touch eth1
[10:31] <asac> ok
[10:31] <asac> start wpa_supplicant and add interface through _cli
[10:31] <asac> then go to cli console
[10:31] <calc> i killed it to be certain it doesn't do anything odd
[10:31] <asac> yes
[10:31] <asac> if there was an instance running
[10:31] <asac> kill wpa
[10:31] <calc> eth1 came up when i shut it down which was odd as well so i downed it again
[10:31] <asac> et al
[10:32] <asac> calc: is NetworkManager still running?
[10:32] <asac> otherwise ifdown eth1
[10:32] <asac> should down it
[10:32] <asac> or if it doesn't do
[10:32] <asac> ifconfig eth1 down
[10:32] <calc> network manager is down and avahi is as well
[10:32] <calc> i killed the running wpa and restarted it with the log
[10:32] <asac> good
[10:33] <asac> 1. add interface
[10:33] <calc> scrollback lost the add interface command
[10:33] <asac> 2. go to wpa_cli
[10:33] <asac> 3. ap_scan 1
[10:33] <asac> 3. add_network
[10:33] <asac> 5. set_network 0 ssid "YOUR ESSID"
[10:34] <calc> what was the command for interface_add you mentioned before
[10:34] <asac> wpa_cli -g/var/run/wpa_supplicant.global interface_add eth1  ""  "" /var/run/wpa_supplicant.run
[10:34] <calc> drop the .run part?
[10:35] <calc> the .run causes a hang, so i dropped it
[10:38] <calc> asac: ok trying the open ap now
[10:38] <calc> asac: still times out
[10:39] <asac> calc:
[10:39] <asac> hehe
[10:39] <asac> i forgot something
[10:39] <asac> please disable_network 0
[10:39] <asac> then set your key
[10:39] <asac> set_network 0 psk "passphrase"
[10:39] <asac> then enable
[10:39] <calc> ok for the wpa2 one?
[10:39] <asac> yes
[10:41] <calc> i get a key mismatch message in the logs
[10:41] <asac> what does scan_results show you?
[10:41] <asac> do you see events on wpa_cli console as well? what do they say?
[10:42] <calc> 00:0c:41:f7:09:53 2462 220 [WPA-PSK-CCMP] [WPA2-PSK-CCMP]  calc
[10:42] <calc> 00:14:bf:2a:5f:e1 2437 202 vinther
[10:43] <asac> that looks not like what i have ... but should be good
[10:43] <calc> do i need to do something to tell wpasupplicant to use wpa2?
[10:43] <asac> hmmm ... i think not
[10:43] <asac> does WPA have a different passphrase?
[10:44] <asac> list_networks ?
[10:44] <asac> what does give?
[10:44] <calc> 0 calc any
[10:44] <asac> ok
[10:44] <asac> try ap_scan2
[10:44] <asac> try ap_scan 2
[10:44] <asac> then reassociate
[10:45] <calc> meaning i need to do the add_network/set_network again?
[10:45] <asac> no
[10:45] <asac> that is remembered
[10:45] <asac> maybe disable_network before
[10:45] <asac> but shouldn't matter though
[10:46] <calc> add_network returned 1
[10:46] <asac> he?
[10:46] <asac> you don't need to add_network
[10:46] <calc> ok
[10:46] <asac> just type reassociate :)
[10:46] <asac> at best remove network 1 now :)
[10:46] <asac> who knows :)
[10:47] <calc> 0 calc any [CURRENT] 
[10:47] <asac> yes
[10:48] <calc> timed out so far
[10:48] <asac> ap_scan 2 ?
[10:48] <calc> scan_results only shows vinther right now
[10:48] <asac> set ap manually
[10:48] <asac> disable_network
[10:48] <asac> set_network bssid AP:AP:AP...
[10:48] <asac> enable
[10:49] <asac> calc do you get new scan_results if you run just scan for once?
[10:49] <calc> yea calc showed up again
[10:49] <asac> good
[10:50] <asac> set bssid please then reassociate/enable network
[10:50] <asac> you sure you have psk set?
[10:50] <calc> trying again
[10:51] <calc> i reset the psk again to make certain
[10:51] <calc> remember when doing this through NM it kept asking for the password over and over and over again
[10:51] <calc> so it would seem that it doesn't care if i give it a password
[10:52] <calc> it says No keys have been configured - skip key clearing
[10:52] <calc> not sure if that means it doesn't like what i tell it for key
[10:53] <calc> asac: ^
[10:55] <asac> hmm
[10:56] <asac> look at help
[10:56] <asac> there is a capabilities entry
[10:56] <asac> calc: can you get a few of those?
[10:56] <asac> e.g. what do you get for key_mgmt?
[10:56] <asac> and others?
[10:57] <calc> NONE IEEE8021X WPA-EAP WPA-PSK
[10:57] <calc> so should it be set_network 0 WPA-PSK "password" ?
[10:57] <stgraber> asac: if that's his ipw3945 and NM unable to connect, I may have a similar issue (working 1/10 when unloading ipw3945 + reload NM and nm-applet)
[10:58] <calc> ah ha!
[10:58] <calc> i had set key-mgmt to none earlier
[10:58] <calc> you have to set key-mgmt and the psk both to use it
[10:59] <calc> it might have a chance of working now
[10:59] <asac> stgraber: can you look the log for today for me and calc on this channel?
[10:59] <calc> still timed out, gar
[10:59] <asac> bssid is set?
[10:59] <asac> to ap address?
[11:00] <calc> asac: is there a way to dump current settings?
[11:00] <calc> to see what it thinks i have set so far
[11:00] <asac> dunno
[11:00] <asac> get_network ssid ?
[11:00] <asac> get_network 0 ssid?
[11:00] <asac> no idea if such a command exists
[11:00] <calc> yea bssid is set along with ssid
[11:01] <calc> asac: does wpa use wireless-tools for any of this or just its own code?
[11:02] <asac> it uses wireless-tools
[11:02] <calc> stgraber: i finally got it to partially work earlier today but its very flakey
[11:02] <asac> lib
[11:02] <asac> libwt
[11:02] <calc> asac: hmm maybe we should try updating that then?
[11:02] <asac> calc: yes
[11:02] <calc> it works when it feels like it currently, which isn't often for me, heh
[11:02] <asac> i hope we have tested enough to say that wpasupplicant as in gutsy is really broken :)
[11:02] <asac> or wireless tools
[11:02] <calc> yea
[11:02] <asac> but i doubt that for now
[11:03] <calc> it definitely looks broken here
[11:03] <asac> anyway
[11:03] <asac> you have to respin wpasupplicant as well iirc
[11:03] <calc> it works immediately and every time in feisty and about 1% of the time in gutsy so something is broken somewhere
[11:03] <asac> because its linked against libwt.so.2x which is still old version
[11:03] <calc> ah
[11:03] <asac> calc: yes
[11:03] <asac> calc: it might be that you should use my wpasupplicant
[11:03] <calc> asac: do you happen to have a way to build amd64 stuff easily? i just have this live cd right now
[11:03] <asac> e.g. 0.5.8
[11:04] <asac> calc: what do you want?
[11:04] <asac> wpasupplicant 0.5.8 (latest stable vs. latest development which we have in gutsy) ?
[11:04] <calc> asac: amd64 version of whatever is needed to see if the api change is the issue?
[11:04] <stgraber> calc: ok, I've just read a good part of the backlog and this seems very very similar
[11:04] <calc> asac: i guess that would be a good place to start?
[11:04] <asac> stgraber: look how we tried to use the wpa_supplicant
[11:05] <asac> and wpa_cli manually
[11:05] <stgraber> asac: ok, I'll give a manual wpa_supplicant a quick try, but I already tried this afternoon without much success
[11:05] <asac> what waas the problem?
[11:06] <asac> calc: so what version of wireless tools do you need?
[11:06] <asac> isn't that in gutsy already?
[11:06] <calc> asac: well debian has the pre22 version, and the kernel is 22 so would that work?
[11:06] <calc> asac: oh hmm maybe?
[11:07] <stgraber> asac: in some case it doesn't even seem to associate with the AP, in some others it does and the key is set (iwconfig) but no green light in NM, in some case it doesn't even try to associate and keeps being connected to another AP ...
[11:07] <calc> the wireless-tools in ubuntu is pre20 which is from april
[11:07] <stgraber> asac: I just do this wpa-supplicant test and I'm back here
[11:07] <calc> is the pre22 the one with 22 api support?
[11:09] <asac> hmmm there is an outstanding merge for wireless-tools ?
[11:09] <asac> calc: no idea ... people claim it
[11:10] <calc> yea
[11:10] <calc> debian is two rev's newer than ubuntu afaict
[11:10] <calc> http://http.us.debian.org/debian/pool/main/w/wireless-tools/wireless-tools_29~pre22-1.dsc
[11:11] <calc> http://archive.ubuntu.com/ubuntu/pool/main/w/wireless-tools/wireless-tools_29~pre20-1ubuntu1.dsc
[11:12] <stgraber> asac: ok, wpa_supplicant manual test succeded (WPA PSK TKIP), I just had to iwconfig eth3 essid "essid" and it associated, then dhclient3 and everything work. I then tried with NM and it didn't manage to connect (looking at iwconfig, one second it's associated but without the key, next second it's no longer, then it seems to be correctly associated but the second after it switched to another AP and NM ask for the pass (even if already spec
[11:12] <calc> +wireless-tools (29~pre22-1) unstable; urgency=low
[11:12] <calc> +
[11:12] <calc> +  * New upstream release.
[11:12] <calc> +
[11:12] <calc> + -- Guus Sliepen <guus@debian.org>  Sun, 01 Jul 2007 18:03:58 +0200
[11:12] <calc> +
[11:12] <calc> +wireless-tools (29~pre21-2) unstable; urgency=low
[11:12] <calc> +
[11:12] <calc> +  * Don't look at LINUX_VERSION_CODE, only use generic header files in
[11:12] <calc> +    iwlib.h. Closes: #425485
[11:12] <calc> +
[11:12] <calc> + -- Guus Sliepen <guus@debian.org>  Tue, 22 May 2007 10:27:46 +0200
[11:12] <calc> +
[11:12] <calc> +wireless-tools (29~pre21-1) unstable; urgency=low
[11:12] <calc> +
[11:12] <calc> +  * New upstream release. Closes: #421569
[11:12] <calc> +
[11:12] <calc> + -- Guus Sliepen <guus@debian.org>  Thu, 03 May 2007 13:55:01 +0200
[11:12] <xxxxx1> ^_x
[11:13] <asac> stgraber: how did you do manual? with wpa_cli ?
[11:13] <asac> stgraber: you shouldn't need to use iwconfig at all
[11:13] <asac> stgraber: e.g. just wpa_cli commands
[11:13] <stgraber> asac: wpa_supplicant -Dwext -ieth3 -c wpa.conf
[11:13] <asac> yeah ... thats not that impressive
[11:13] <asac> start it like in backlog
[11:13] <asac> and let it detect everything on its own
[11:13] <asac> :)
[11:13] <stgraber> wpa.conf being my network config with : ssid, key_mgmt, proto, pairwise, group and psk set
[11:13] <asac> thats what is needed for entwork manager
[11:15] <asac> stgraber: wpa_supplicant -g /var/run/wpa_supplicant.global -dd 2>&1 | tee /tmp/wpa.debug.log
[11:15] <asac> in a second terminal add interface like:
[11:15] <asac> wpa_cli -g/var/run/wpa_supplicant.global interface_add eth1 "" "" /var/run/wpa_supplicant.run
[11:15] <asac> then enter wpa_cli:
[11:15] <asac> wpa_cli -ieth1
[11:17] <stgraber> Could not connect to wpa_supplicant - re-trying
[11:17] <stgraber> and other window stuck at half of my MAC address
[11:17] <asac> hmm
[11:17] <stgraber> Own MAC address: 00:19:d2:
[11:17] <asac> maybe try to specify driver
[11:17] <asac> wpa_cli -g/var/run/wpa_supplicant.global interface_add eth1 "" wext /var/run/wpa_supplicant.run
[11:18] <asac> bur restart supplicant first
[11:18] <asac> do you have eth1 ?
[11:18] <asac> adapt according where your interface is
[11:18] <stgraber> no, eth3 but I s/eth1/eth3/
[11:19] <asac> k
[11:19] <asac> ah
[11:19] <asac> sorry
[11:19] <asac> wpa_cli -g/var/run/wpa_supplicant.global interface_add eth1 "" wext /var/run/wpa_supplicant
[11:19] <asac> use that
[11:19] <asac> :)
[11:20] <stgraber> ok, I'm in interactive mode now
[11:20] <asac> cool
[11:21] <asac> set ap_scan 1
[11:21] <asac> e.g.
[11:21] <asac> ap_scan 1
[11:21] <asac> > add_network
[11:21] <asac> > set_network 0 ssid "youressid"
[11:21] <asac> set_network 0 psk "yourwpapassphrase"
[11:21] <asac> > enable_network
[11:21] <asac> and see what happens
[11:22] <stgraber> no suitable AP found :(
[11:22] <calc> "The main features of the latest beta is WE-21 support (long/short retry, power saving level, modulation), enhanced command line parser in iwconfig, scanning options, more WPA support, sysfs symlinks and udev compatibility in ifrename and more footprint reduction tricks"
[11:23] <asac> stgraber:
[11:23] <stgraber> it says "ssid missmatch" but the ssid I provided is correct and shown in wpa_supplicant scan results ...
[11:23] <asac> > scan
[11:23] <asac> ah
[11:23] <asac> ok
[11:23] <asac> what capabilities do you see?
[11:23] <asac> do they look sane?
[11:24] <asac> is psk good?
[11:24] <asac> or isn't there any authentication going on?
[11:24] <stgraber> it doesn't even try
[11:24] <stgraber> it simply says : ssid missmatch, pass
[11:24] <asac> ok
[11:24] <stgraber> and try with the next one, but ssid matches ...
[11:24] <asac> thats what client says?
[11:24] <asac> or supplicant?
[11:24] <asac> what happens in supplicant terminal?
[11:25] <stgraber> supplicant
[11:25] <asac> ah
[11:25] <asac> do you see anything on client?
[11:25] <asac> or nothing?
[11:25] <stgraber> 1: 00:14:d1:c0:39:80 ssid='graber-wifi' wpa_ie_len=26 rsn_ie_len=0 caps=0x11 skip - SSID mismatch skip - disabled
[11:25] <stgraber> that's in wpa_supplicant
[11:25] <asac> hmm
[11:25] <asac> and get_network 0 ssid ?
[11:26] <stgraber> clients just says OK :)
[11:26] <asac> is 'graber-wifi' ?
[11:26] <stgraber> it simply says : ssid missmatch, pass> get_network 0 ssid
[11:26] <stgraber> FAIL
[11:26] <stgraber> I hate this copy/paste :)
[11:26] <stgraber> so, it returns fail
[11:26] <asac> yeah
[11:27] <stgraber> even after returning OK after the add_network and psk
[11:27] <asac> disable_network
[11:27] <calc> stgraber: which arch are you on?
[11:27] <asac> then ap_scan 2
[11:27] <stgraber> calc: amd64
[11:27] <calc> stgraber: ok
[11:27] <calc> stgraber: same as me
[11:27] <calc>  * V21 to V22
[11:27] <calc>  * ----------
[11:27] <calc>  *      - Prevent leaking of kernel space in stream on 64 bits.
[11:27] <asac> stgraber: and in addition set_network bssid "yourap"
[11:28] <asac> its a tiny change afaik
[11:28] <stgraber> > set_network 0 bssid "graber-wifi"
[11:28] <stgraber> FAIL
[11:28] <asac> just different size macros
[11:28] <calc> stgraber: bssid is hex
[11:28] <asac> stgraber: bssid is access-pointe address
[11:28] <asac> not essid
[11:28] <stgraber> oh, right, sorry :)
[11:28] <asac> 00:00:00...
[11:29] <asac> stgraber: do you have a i386 live cd?
[11:29] <asac> stgraber: to see if it works?
[11:30] <asac> if that would be the case ... it would almost certainly be tools mismatch
[11:30] <stgraber> ok, so this time I got a "Trying to associate with ..." from the client and I see unassociated with iwconfig (key is set)
[11:30] <asac> you are in ap_scan 2 ?
[11:30] <calc> asac: i'll set up a download for i386 here as well
[11:30] <asac> stgraber: can you see if the right capabilities are selected?
[11:31] <asac> get_network 0 key-mgmt
[11:31] <stgraber> FAIL :(
[11:31] <asac> thats so crazy
[11:31] <asac> stgraber: do you have a x86 iso?
[11:32] <stgraber> asac: only Kubuntu i386 Tribe-3 (the last one I tested last week :))
[11:32] <stgraber> but I can quickly download an ubuntu one, it'd take something like 10-15 minutes
[11:33] <asac> stgraber: please try
[11:33] <asac> i will be awake for another half an hour or so :)
[11:34] <stgraber> asac: ok, I'm downloading the ubuntu desktop iso on my server so I can test the Kubuntu one now :)
[11:36] <asac> cool
[11:43] <stgraber> asac: ok, I'm on a kubuntu livecd now
[11:43] <stgraber> asac: connecting to an open AP works, connecting to the WPA one keep asking the password
[11:44] <asac> stgraber: does open work on amd64?
[11:44] <stgraber> asac: manually yes, not with NM though
[11:46] <asac> ok nm might be broken still
[11:46] <asac> and manually wpa?
[11:46] <asac> e.g. like we did?
[11:48] <calc> asac: i'll have the cd downloaded in about 17m if you want me to do any i386 testing
[11:51] <stgraber> calc: looks like wpa_supplicant doesn't see my network now ... I have something like 4-5 networks here but spread on different channels and the network I try to connect to is MIMO so I don't really see why I don't see it now ...
[11:51] <stgraber> calc: oh, it just managed to connect :)
[11:52] <calc> stgraber: heh
[11:52] <stgraber> http://paste.stgraber.org/2257
[11:54] <asac> stgraber: so what did you do?
[11:55] <stgraber> http://paste.stgraber.org/2258
[11:56] <asac> stgraber: cool
[11:56] <asac> so it works on i386?
[11:56] <asac> but doesn't on amd64
[11:56] <asac> cool
[11:56] <calc> could that be due to the macro thing i pasted about earlier?
[11:56] <asac> yes
[11:57] <calc> ok
[11:57] <asac> its in header ... so its inlined
[11:57] <asac> afaik wireless tools have a copy of that header for each version they support
[11:57] <calc> i should know soon if my system works in i386 mode
[11:57] <asac> calc: nm might be broken
[11:57] <calc> i was having trouble in the past in i386 but it may be resolved with tribe-3
[11:57] <stgraber> asac: now it also work with KNetworkManager, so yes that may be an amd64 specific bug
[11:58] <asac> stgraber: would be great if you could test on gnome nm applet as well
[11:58] <asac> because thats the code i know
[11:58] <calc> 6m left then burning
[11:58] <stgraber> asac: I have the ubuntu i386 iso ready, just le met reboot and burn it
[11:58] <asac> stgraber: great
[11:58] <asac> i wait another 10 minutes then :)
[12:02] <stgraber> let's burn this iso :)
[12:06] <calc> writing cd
[12:06] <asac> oh we got a race ;)
[12:07] <stgraber> 1min remaining
[12:07] <calc> unknown
[12:07] <calc> nautilus one doesn't say for me
[12:08] <asac> nautilus doesn't in gutsy ... shame
[12:09] <stgraber> finished, well the "write disc" option does for me and I think it's nautilus
[12:09] <stgraber> be back in a minute
[12:09] <calc> done