=== tkamppeter_ is now known as tkamppeter
[08:29] <didrocks> hi folks :)
[08:29] <mvo> hey didrocks
[08:29] <mvo> hey huats
[08:29] <didrocks> hi mvo
[08:30] <seb128> lut didrocks huats
[08:30] <seb128> hey mvo
[08:30] <didrocks> plop seb128 ;)
[08:30] <mvo> seb128: I have a very strange issue wihen I login via gdm in latest jaunty, my mouse is broken, can left click on anything. but when I kill gdm and just run startx everything is normal? it could be my HW, but I suspect its something else
[08:30] <huats> hey seb128 and mvo
[08:30] <huats> morning everyone
[08:32] <seb128> mvo: the mouse is broken on the gdm screen or in your session?
[08:32] <mvo> in the session
[08:32] <mvo> I think its fine in gdm
[08:32] <seb128> weird
[08:32] <mvo> but i need to verify, I never use it there
[08:33] <seb128> since GNOME didn't change recently I would tend to blame xorg rather than GNOME
[08:33] <mvo> it seems to be happening after something is loaded
[08:33] <mvo> right
[08:33] <mvo> I only recently upgraded this machine
[08:33] <seb128> any mouse error in Xorg.0.log?
[08:33] <seb128> you can move the mouse pointer and right click?
[08:33] <mvo> I can move the pointer, haven't tried right click
[08:34] <mvo> I will do that soonish (after applying todays updates and reboot) :)
[08:34] <mvo> thanks!
[08:35] <didrocks> seb128: I tried to work on bit on gnome-games' package and I have two question
[08:35] <seb128> didrocks: tried a bit? that's not enough ;-)
[08:36] <didrocks> ;-)
[08:36] <seb128> just ask ;-)
[08:36] <didrocks> seb128: the libtool version is not bumped to the right version, even in jaunty (I just realized it after pbuilder login, apt-get install build-dep... :( and tried to autoreconf..)
[08:36] <didrocks> http://paste.ubuntu.com/105460/
[08:37] <didrocks> so, I have to update the libtool for it, I think
[08:37] <seb128> didrocks: ?
[08:37] <seb128> didrocks: do you are an autoconf patch?
[08:37] <seb128> have
[08:37] <didrocks> yes
[08:37] <didrocks> and generate it
[08:37] <seb128> that means you didn't do it correctly
[08:37] <didrocks> hum
[08:37] <seb128> try running autoreconf rather to update it
[08:38] <didrocks> so, what I do is the following:
[08:38] <didrocks> apply the patch to the configure.in (with the right patch system)
[08:38] <didrocks> then "autoreconf -i --force"
[08:38] <didrocks> and generate the new patch against ./configure
[08:39] <seb128> Keybuk: hey
[08:39] <seb128> Keybuk: do you have some clue about what to do when running into a such error, I got that recently on a package too I think and autoreconf didn't solve it either
[08:39] <didrocks> (and I also tried, in the case, to remove aclocal.m4, as I had no trace of change against it, but it is regenerate)
[08:39] <seb128> didrocks: Keybuk knows about libtool so he might be helpful there
[08:39] <didrocks> great, will wait for him
[08:40] <didrocks> but you see nothing's wrong with this procedure?
[08:40] <didrocks> nothing*
[08:41] <seb128> didrocks: no, autoreconf should be updating everything that needs to be updated
[08:41] <seb128> didrocks: what do you call against configure? you need to get the changes for all the files autoreconf updates
[08:42] <didrocks> seb128: ok, will see Keybuk's hints so
[08:42] <seb128> if the package is using quilt that's the suck, either do a find . and quilt add everything or update the patch using some other way
[08:43] <didrocks> seb128: that's what I did (and yeah, it is using quilt). I think I have missed nothing
[08:43] <didrocks> (and it is shouting at aclocal.m4, which I remember, I have explicitely "quilt add" it)
[08:47] <didrocks> seb128: my second question was to activate or not cluttering
[08:47] <didrocks> from NEWS file:
[08:47] <didrocks> Therefore, at this time, we recommend that clutter only be enabled by default
[08:48] <didrocks> by distributors that ensure that OpenGL acceleration is working for hardware
[08:48] <didrocks> from the three major vendors: Intel, NVidia and ATI.
[08:48] <didrocks> but we are not sure that OpenGL acceleration is activated on the final user desktop
[08:48] <didrocks> so, I think we don't have to activate it
[08:48] <seb128> don't no
[08:49] <seb128> we don't have lot of CD space to waste anyway
[08:49] <seb128> let's wait for upstream to stabilize that before using it in ubuntu
[08:49] <didrocks> seb128: we agree, but I prefer to have your ack :)
[09:25] <Keybuk> yeah
[09:25] <Keybuk> that error is because you used --force
[09:28] <seb128> Keybuk: shouldn't autoreconf update everything when you use the force option?
[09:38] <Keybuk> yes
[09:38] <Keybuk> except it won't downgrade aclocal files
[09:38] <Keybuk> (because it can't)
[09:39] <seb128> ah
[09:39] <Keybuk> you generally don't want --force
[09:39] <Keybuk> that would have not downgraded libtool
[09:39] <seb128> Keybuk: you could perhaps update libtool to 2.2.6 to avoid such issues? ;-)
[09:39] <Keybuk> (without that)
[09:39] <Keybuk> yes, I should
[09:39] <seb128> that's what debian experimental has
[09:39] <seb128> and those tarballs are rolled on debian experience install apparently
[09:40] <seb128> experience -> experimental
[09:40] <didrocks> Keybuk: so, why I still have this issue when I rm aclocal.m4 ?
[09:41] <didrocks> (aclocal.m4 is then generated)
[09:41] <didrocks> sorry, I must admit my knowledge in autoconf tools are quite limited :/
[09:43] <Keybuk> didrocks: does the package have an m4 directory?
[09:43] <Keybuk> (ie. are the contents of aclocal just include lines)
[09:43] <didrocks> Keybuk: can't look at the aclocal file right now, but yeah, there is an m4 directory
[09:44] <Keybuk> you'd need to remove the files from there too
[09:44] <didrocks> so, while libtool is not update. I have to rm this directory as --force will not downgrade them?
[09:44] <didrocks> ok, right :)
[09:44] <didrocks> thanks a lot!
[09:45] <didrocks> (oh, without the "!", I learnt some days ago, it was rude in English ;))
[09:45] <seb128> I doubt that will work correctly
[09:45] <didrocks> seb128: you think that the new configure.in is dependant of the new libtool version?
[09:45] <didrocks> dependent*
[09:45] <seb128> no, but the m4 directory is not only autotools files, it has some specific macros defined there
[09:46] <Keybuk> yeah, you need to only rm specific ones
[09:46] <seb128> the easier way is really to get Keybuk to do the libtool update and use that version ;-)
[09:46] <didrocks> ok, will give it a try. But if I can help to update libtool package...
[09:47] <didrocks> seb128: you're right, less work for me :)
[09:47] <seb128> ok, I'm away for half an hour, bbl
[10:15] <Keybuk> new libtool uploaded
[10:19] <seb128> Keybuk: thanks
[10:33] <didrocks> Keybuk: thanks :)
=== asac_ is now known as asac
[10:34] <didrocks> seb128: so, I have some work to do this week-end :) I am pretty confident with the new libtool version now
[10:34] <seb128> didrocks: ok good ;-)
[11:37] <mpt> ArneGoetje, I've updated the mockups in <https://wiki.ubuntu.com/JauntyLanguageSelectorImprovements> and specified the behavior details.
[11:44] <mpt> ArneGoetje, I don't see a spec for the font settings anywhere
[17:48] <mpt> asac, rickspencer32: Do 3G connections have signal strength in the same way wireless connections do?
[17:56] <rickspencer32> mpt: not that I can see
[17:56] <rickspencer32> mpt: http://theravingrick.blogspot.com/2009/01/ubuntu-rocks-mobile-broadband.html
[18:07] <Nafallo> haha. I'm SO going to plug in my parents 3G dongle and show them why they are wrong.
[18:12] <rickspencer32> Nafallo: note that Verizon implies to customers that they need that NZAccess Manager app
[18:12] <rickspencer32> I assume it's spy ware, but don't know that for a fact
[18:13] <Nafallo> doesn't all of them tell lies based of little knowledge? :-)
[18:13] <rickspencer32> I suppose
[18:14] <rickspencer32> I think that's part of what happened to that poor lady who got Ubuntu from Dell. Her ISP told her she couldn't connect to the internet without their software
[18:14] <rickspencer32> What reason would she have to doubt them?
[18:14] <Nafallo> yea. I assume so as well.
[18:28] <calc> rickspencer32: probably not spyware just lack of training employees to know how to do it any other way
[18:31] <dobey> rickspencer32: it's not so much spyware as it is a single point of failure for customer service to deal with. it's much easier to train your 10,000 people sitting in a call center to deal with issues from one program, rather than all the possible combinations of ways to configure networking across the board
[18:34] <rickspencer32> calc: dobey: you make me feel cynical
[18:35] <rickspencer32> I also suppose that Windows probably doesn't work well with 3g, so they had to do some plumbing themselves. They wouldn't expect an OS to be able to adapt fast enough to just work
[18:35] <dobey> rickspencer32: it's easy to feel cyncical about the corporate bottom dollar problem :)
[18:36] <dobey> rickspencer32: well, Vista probably has some built-in stuff, where XP does not, and so it's easier to just have the one program there again for support
[18:37] <Nafallo> dobey: Vista had problems with regular DHCP on my last flatmates laptop... just saying :-)
[18:37] <dobey> rickspencer32: i know for example, the WPA support in XP is rather crap, so even though the wireless card in my laptop works in XP without the special intel program, it won't work with WPA G networks
[18:37] <dobey> rickspencer32: so i have to use the intel program to use wireless
[18:38] <dobey> Nafallo: so does my xbox360. think MS just does some weird stuff to DHCP, and it breaks horribly in some cases
[18:38] <Nafallo> agreed :-)
[18:39] <dobey> it's like how outlook mobile on my phone doesn't seem to want to do smtp for some reason
[18:39] <Nafallo> and then you get some weird mode like restricted internet or whatever... which I think means that you're on local link.
[18:40] <dobey> yeah, it does a weird thing where it assigns a default local ip
[18:40] <Nafallo> oh. not link local then?
[18:41] <dobey> Nafallo: i've seen a similar problem before, but i'm pretty sure it was a hardware problem, because neither wireless nor hardwire would work, even if i manually configured the ip
[18:41] <Nafallo> this wasn't. it worked from time to time :-)
[18:41] <dobey> Nafallo: well it assigns a local ip, and i think actually doing zeroconf stuff over wireless depends on some other settings, and whether or not you set up a network
[18:42] <dobey> link local with only yourself isn't particularly useful
[18:42] <Nafallo> :-)
[18:42] <Nafallo> yea... well... my Ubuntu didn't fail so... ;-)
[18:43] <Nafallo> even if it had, I've de-installed the link local stuff :-)
=== johanbr_ is now known as johanbr
=== mvo__ is now known as mvo
[20:21] <chrisccoulson> ping mvo - i notice you've got a branch of update-notifier that uses EggSmClient. Is that going to appear in Jaunty at all?
[20:21] <mvo> chrisccoulson: I have not fully made up my mind about it
[20:22] <mvo> chrisccoulson: I created it to help the effort to get rid of libgnome as a dependenc
[20:22] <mvo> y
[20:22] <chrisccoulson> the only reason i ask is because of bug 302326
[20:22] <ubottu> Launchpad bug 302326 in update-notifier ""Restart Now" informational applet does not work" [Medium,In progress] https://launchpad.net/bugs/302326
[20:22] <mvo> I also don't quite remember if that was all dependencies in u-n against libgnome
[20:23] <mvo> oh, thanks chrisccoulson
[20:23] <mvo> good catch
[20:23] <chrisccoulson> i just wrote a patch that uses DBus to restart the system
[20:23] <mvo> chrisccoulson: I think for now re-adding gnome_programm_init() is fine
[20:23] <chrisccoulson> but that was before i noticed your EggSMClient branch
[20:24] <mvo> I was thinking about the dbus approch
[20:24] <mvo> but I was afraid of breaking compatiblity with xubuntu
[20:24] <chrisccoulson> the dbus patch is quite small, and I just tested it out
[20:24] <mvo> (or kde)
[20:24] <chrisccoulson> ah, yeah, i hadnt thought of that
[20:24] <mvo> the nice thing about the current way is that its truely cross desktop
[20:24] <mvo> (everything else I dislike on the xmpp stuff) :)
[20:25] <chrisccoulson> yeah, it would be nicer if we could just use DBus
[20:25] <chrisccoulson> i can do a patch that reinstates gnome_program_init if you like?
[20:25] <mvo> chrisccoulson: that would be very nice
[20:25] <chrisccoulson> no problem, i'll work on that
[20:25] <mvo> chrisccoulson: its maintained in bzr, but normal diff is just fine as well
[20:26] <chrisccoulson> i did the Dbus patch in a bzr branch, so I can do the new patch there as well
[20:26] <mvo> chrisccoulson: nice
[20:27] <mvo> I will be around for another 1-2h - if I'm gone, just add main-sponsors to the report and someone will surely pick it up :)
[20:27] <chrisccoulson> i'll do that - thanks