[00:05] <sektor_1> Hello. I noticed that sshd will not start at boot if the ListenAddress Option in sshd_config is set to a IPv4 address other than 0.0.0.0. Should I report this?
[00:09] <afflux> good night.
=== asac_ is now known as asac
[01:34] <greg-g> sektor_1: please report any bugs you find.  It is also a good idea to search Launchpad to see if it has been reported already or not.
[01:39] <sektor_1> greg-g: okay. I searched https://launchpad.net/ubuntu/+bugs and did not find anything that sounds like this problem. I will report that. Thank you and good night.
[04:50] <mattias> someone that cna sort some problems out with deluge ...
[04:50] <mattias> i have fond some errors in the deluge bittorrent errors ...
[04:51] <mattias> as well as in the wireless features in 7.10
[04:53] <mattias> deluge bit torrent if i try to import torrent files than the deluge turn off and in the lastest version deluge refuses to start ...
[04:54] <mattias> the wireless does not work  if my wireless ap is invisible by its ssid ...
[04:56] <mattias> any sollution to all of this ?
[04:59] <mattias> good luck everybody, seems to be the wrong place to get help ..
=== blueyed_ is now known as blueyed
=== macd_ is now known as macd
[06:33] <DOOM_NX> good morning
=== asac_ is now known as asac
[08:44] <Gnine> after apt-get upgrade: dpkg: status database area is locked by another process
[08:44] <Gnine> E: Sub-process /usr/bin/dpkg returned an error code (2)
[08:45] <Gnine> 8.04 2.6.24-12-generic
[08:46] <Gnine> starting partial upgrade via update-manager
[08:57] <Gnine> completed. restarting.
[09:01] <danage> anybody know the bug where the mount directories under /media/ are not removed and you get (Name)_ and (Name)__ and (Name)___ and so forth?
[09:02] <Gnine> grub failed updating kernel list
[09:19] <Arby>  Gnine: have you filed a bug in launchpad?
[09:19] <Arby> reports on irc tend to get lost or forgotten
[09:20] <Gnine> 10-4
[09:21] <Gnine> grub has been like this (in my case) since -12-generic
[09:22] <Gnine> i am going to just manually do it
[09:22] <Arby> ok include that in the report
[09:22] <Arby> and if you could attach the file /var/log/dpkg.log that might tell us what dpkg was up to
[09:23] <Arby> also check if there are any log files in /var/log/dist-upgrade
[09:23] <Arby> if there are include those
[09:23] <Gnine> i might as well check if there is an existing bug about it. havent checked.
[09:24] <Arby> indeed
=== Arby_ is now known as Arby
[10:18] <afflux> morning
[10:19] <afflux> what's the policy on milestones? Is this bugcontrol's job or only for devs?
[10:32] <Arby> could someone check if bug 215446 is a duplicate of bug 205836 please?
[10:32] <ubotu> Launchpad bug 215446 in update-manager "dependency problems - leaving unconfigured" [Undecided,Incomplete] https://launchpad.net/bugs/215446
[10:32] <ubotu> Launchpad bug 205836 in update-manager "Stack Smashing Still Happening with libc6_2.7-9ubuntu2_i386" [Undecided,Triaged] https://launchpad.net/bugs/205836
[10:32] <Arby> I think it is but I'd like a second opinion
[10:33] <james_w> Arby: looks like it to me.
[10:35] <Arby> james_w: thanks
[10:36] <Arby> james_w: which one would you make the main report?
[10:36] <Arby> they're both pretty comprehensive
[10:44] <james_w> there's one of these that is being worked on, let me find it
[10:45] <james_w> https://bugs.edge.launchpad.net/ubuntu/+source/glibc/+bug/205079
[10:45] <ubotu> Launchpad bug 205079 in linux-restricted-modules-2.6.24 "kubuntu Hardy Heron could not install libc6" [High,Fix released]
[10:45] <james_w> both should be duplictes of that I think
[10:45] <Arby> ok
[12:30] <secretlondon> hggdh, I'm gonna have another go at getting useful info on bug #151536
[12:30] <ubotu> Launchpad bug 151536 in evolution-data-server "[MASTER] E-D-S hangs on login and uses 100% cpu" [High,Triaged] https://launchpad.net/bugs/151536
[14:10] <hggdh> secretlondon: ah, thanks. Sorry for the delay, but I was sleeping :-)
[14:17] <secretlondon> hggdh, no problem :)
[14:19] <hggdh> actually, this was disturbing... I slept from midday to 15:00... I must be sick, or something
[14:21] <hggdh> gotta get me coffee, a cafè long will do the trick, I hope
[15:25] <Arby> any gnome users come can tell me what gnome-menu-extended is?
[15:25] <Arby> it seems to be causing bug 213320
[15:25] <ubotu> Launchpad bug 213320 in update-manager ""update manager" - error installing "gnome-menu-extended_0.8-1_all.deb"" [Undecided,Incomplete] https://launchpad.net/bugs/213320
[15:26] <Arby> searching google takes me here http://www.gtk-apps.org/content/show.php/Gnome+Menu+Extended+(Debian+Package)?content=73515
[15:26] <andrea-bs> Arby: it's not in Ubuntu: http://packages.ubuntu.com/gnome-menu-extended
[15:27] <Arby> so downloading that package and then installing with dpkg or GDebi would confuse synaptic yes?
[15:27] <Arby> i.e the package management system is looking for something that doesn't exist
[15:34] <andrea-bs> Arby: the problem is in the prerem script gnome-menu-extended package, which is not in Ubuntu so the bug should be reported upstream
[15:35] <Arby> ok
[15:36]  * Arby looks for the appropriate place to forward
[15:37] <Arby> where would I find out if it's a part of gnome
[15:37] <Arby> or a completely independent thing?
[15:37] <secretlondon> google?
[15:37] <andrea-bs> gnome.org
[15:38] <Arby> I'm looking at gnome.org now
[15:38] <Arby> I'm a kde person so I don't know the gnome structure
[15:40] <Arby> no entries for gnome-menu-extended in the gnome bugzilla
[15:43] <andrea-bs> it seems like it has no upstream bugtracker
[15:44] <Arby> that was my conclusion
[15:44] <Arby> I guess I just advise them to report it to the original author
[15:44] <Arby> can't do much else
[15:44] <andrea-bs> yes, this is the best thing to do
[15:45] <Arby> done
[15:46] <pochu> apport shouldn't have reported that bug in the first place, as that wasn't an Ubuntu package...
[15:47] <Arby> the finer points of apport are beyond me I'm afraid :)
[15:47] <andrea-bs> pochu: maybe the user has reported the bug using Help→Report a problem
[15:48] <Arby> could it be that -> Package: gnome-terminal 2.18.2-0ubuntu1 which triggered apport
[15:49] <Arby> or is that something the user would fill in
[15:51] <hggdh> Arby: if the bug is about a package we do not provide, go ahead and close invalid
[15:51] <Arby> hggdh: ok
[15:52] <pochu> Arby: yes, it could have been that
[15:52] <Arby> done, bugs--
[15:52] <pochu> otherwise I would have expected apport to reject it
[15:52] <pochu> andrea-bs: no, it was an apport report
[15:52] <Arby> next up is bug 200191
[15:52] <ubotu> Launchpad bug 200191 in update-manager "System upgrade fails when dbgsym-package are installed (evolution)" [Undecided,Confirmed] https://launchpad.net/bugs/200191
[15:53] <Arby> where do packages like evolution-dbg live now?
[15:53] <andrea-bs> pochu: apport report or apport crash report?
[15:53] <hggdh> Arby: also, just for confirmation, http://packages.ubuntu.com does not show this package for *any* of the Ubuntu versions
[15:54] <andrea-bs> Arby: `evolution-dbg` is in the source package `evolution`: http://packages.ubuntu.com/hardy/evolution-dbg
[15:54] <secretlondon> hggdh, got some gdb stuff for you
[15:55] <hggdh> Arby: deb http://ddebs.ubuntu.com/~ubuntu-archive/ddebs hardy main universe
[15:55] <pochu> andrea-bs: hmm, you're right, it looks like he reported it from help->report in gnome-terminal
[15:55] <hggdh> thanks secretlondon, I guess I will have to have some fun with it ;-)
[15:55] <secretlondon> hggdh, for some meaning of 'fun' anyway ;)
[15:55] <hggdh> a sick one at that
[15:56] <Arby> thanks folks
[15:56] <hggdh> welcome Arby, thanks for helping
[15:56] <Arby> I just couldn't find the package in add/remove
[15:56] <Arby> i've found it with synaptic though
[15:56] <hggdh> Arby: the definite source of all Ubuntu packages is https://packages.ubuntu.com
[15:57] <secretlondon> hggdh, if you need any other debug files for the hated bug just yell :)
[15:57] <Arby> I know, I just keep forgetting, oops :)
[15:57] <hggdh> secretlondon: right now I am considering yelling in despair
[15:58] <hggdh> Arby: except for the dbgsyms...
[15:58] <secretlondon> hggdh, evo alarm puts stuff in ~/.xsession-errors about non existant alarms
[15:58] <hggdh> for the dbgsyms, add the line I put out on /etc/apt/sources.list
[15:59] <hggdh> secretlondon: it is a good idea to upload it also -- thanks for noting it
[15:59] <Arby> thanks
[16:00] <hggdh> huh, Arby... s/https/http/
[16:00] <hggdh> sorry
[16:03] <secretlondon> hggdh, i have a fair amount of libecal in there, I think, and just found a libecal evo alarm error in .xession-errors
[16:04] <hggdh> good, perhaps we are getting near the culprit!
[16:04] <secretlondon> it would fit with the setting up a calendar as a possible cause idea
[16:04] <hggdh> secretlondon: yes, and this would match some comments in the bug
[16:04]  * secretlondon hopes this may be the much longed for breakthrough
[16:05] <hggdh> looking at the GDB runs now...
[16:06] <hggdh> (and preempting the resulting headache with a dose of aspirin)
[16:07] <secretlondon> I've got a nice hot bath run waiting for me to finish adding this
[16:07] <secretlondon> and I've told twitter I'll have a party when we fix it ;)
[16:11] <hggdh> :-)
=== emu is now known as emu1982
[16:14] <hggdh> secretlondon: well, I see the message in the .xsession-errors, but (unfortunately) this is on evolution-alarm-notify... which we did not trace...
[16:15] <hggdh> I will have a look at e-a-n to see what type of message is this. But, looking at the gdb BTs, it seems like E-D-S is still trying to initialise, and some required resource is unavailable
=== emu1982 is now known as emu
[16:20] <hggdh> secretlondon: I would like you to try something next time: kill evolution-alarm-notify instead of E-D-S. I wonder if the loop in E-D-S will go away... of course, if you are willing
[16:20]  * hggdh hates not being able to reproduce this bloody bug
=== emu is now known as emu1982
[16:30] <secretlondon> hggdh, i'll try that now
[16:30] <hggdh> secretlondon: thanks, IOU
[16:32] <hggdh> secretlondon: I looked at my .xsession-errors, I also see the same e-a-n errors (three of them in sequence, followed by "Could not create the alarm notify service factory, maybe it's already running..."
=== emu1982 is now known as emu
=== emu is now known as emu1982
=== emu is now known as emu1982
=== emu1982 is now known as emu
[16:46] <secretlondon> hggdh, it didn't stop looping
[16:46] <hggdh> sigh...
[16:46] <secretlondon> when I attached gdb to e-a-n anyway
[16:47] <secretlondon> I haven't actually killed it
[16:47] <hggdh> the hell of it is that it looks, smells, feels to the touch, and behaves like a resource contention (a.k.a. deadlock)
[16:48] <hggdh> secretlondon: try to kill the beast now, lets see if something happens
[16:48] <secretlondon> its stopped!
[16:49] <secretlondon> but gdb didn't stop it, but kill -9 e-a-n did
[16:49] <hggdh> secretlondon: YES!
[16:49] <hggdh> so killing e-a-n *did* stop the loop, correct?
[16:49] <secretlondon> could killing e-a-n cause e-d-s to die too?
[16:49] <hggdh> (just confirming, it sounds too good to be true)
[16:50] <secretlondon> as we know that kill -9 e-d-s makes it go away
[16:50] <secretlondon> killing e-a-n stops the loop
[16:50] <hggdh> no, e-a-n is just an application, killing it should not kill e-d-s
[16:50] <secretlondon> I think I need to reconfirm that without having run gdb first
[16:50] <hggdh> good idea
[16:51] <secretlondon> gonna reboot bbiab
[16:51] <hggdh> (fingers crossed)
[16:52] <jeromeg> does someone know the name of the gtk widget which shows a list of different files with their size, type ... ?
[16:58] <secretlondon> confirmed
[16:59] <secretlondon> I've attached a log from my terminal showing the difference in top once I kill e-a-n
[17:00] <secretlondon> hggdh, well it's a breakthrough, of sorts!
[17:00] <secretlondon> hggdh, would backtraces of e-a-n help?
[17:01] <hggdh> secretlondon: yes
[17:01] <hggdh> I hope
[17:01] <secretlondon> hggdh, okay, i'll do in a sec
[17:01] <hggdh> HUGE thanks, secretlondon
[17:03] <secretlondon> hggdh, the deps of e-a-n should be the same as evo?
[17:03]  * secretlondon is installing the debug libs
[17:03] <hggdh> yes, e-a-n is a piece of e-d-s
[17:03] <hggdh> you should already have the dbgs
[17:03] <secretlondon> the deps of evo itself are different
[17:04] <hggdh> ah, sorry
[17:04] <hggdh> indeed
[17:15] <hggdh> secretlondon: I was wrong, e-a-n is part of Evo, not e-d-s
[17:15] <secretlondon> hggdh, I am installing all of evos deps
[17:15] <secretlondon> it has a LOT :)
[17:15] <hggdh> :-)
[17:15] <secretlondon> I remembered seeing launchpad-foo in gdb when I ran it against e-a-n
[17:16] <hggdh> there are two sets of dbgs for Evo: the dbgsym and the dbg. The dbg is created by the build process itself, and it is one single file. The dbgsyms are created by pitti's process, and they are one for each package
[17:16] <hggdh> so you can install just the dbg, or all the dbgsyms
[17:17] <hggdh> brb
[17:18] <secretlondon> I already have all the dbgsyms for other stuff
[17:23] <hggdh> I am back
[17:24] <secretlondon> I'm downloading the 47 new dbgsym files, then gonna reboot
[17:26] <hggdh> 47??
[17:26] <secretlondon> evo has millions of dependencies
[17:26] <hggdh> ah, for the dependencies
[17:27] <hggdh> probably overkill, but a sane approach nevertheless. Thanks.
[17:29] <secretlondon> rebooting now
[17:33] <Arby> bug 192098 <- should that be marked invalid?
[17:33] <ubotu> Launchpad bug 192098 in update-manager "update-manager confused about package origins" [Undecided,New] https://launchpad.net/bugs/192098
[17:33] <Arby> if someone makes a homebrew package that breaks update manager
[17:34] <Arby> then that's hardly our fault right
[17:41] <hggdh> Arby: guess so, but I do not deal with update-manager... a safer bet, anyway, is to give the package a different version/update level. This might have been the issue
[17:42] <Arby> ok
[17:43] <Arby> I'll check with mvo next time he's around
[17:43] <Arby> update-manager is his territory
[17:43] <hggdh> good idea
[17:44] <secretlondon> hggdh, attached
[17:45] <secretlondon> hggdh, whenever I interrupted always seemed to be the same thing, one of which was poll()
[17:45] <hggdh> thanls, secretlondon, will look at it now
[17:45] <hggdh> you mean in e-a-n?
[17:45] <secretlondon> yep
[17:45] <greg-g> Arby: yeah, for completeness's sake, you could ask for what version name they used for their custom package and what version was offered by the repositories that was not working.
[17:46] <hggdh> k. so e-a-n is waiting... poll() waits on socket I/O (or a timeout)
[17:46] <Arby> greg-g: thanks, will do
[17:47] <greg-g> Arby: no problem
[17:48] <hggdh> I guess if you strace e-a-n, you will see a lot of poll()s
[17:48] <secretlondon> hggdh, worth doing?
[17:48] <hggdh> yes. the more data the better
[17:49] <hggdh> the bts are very much similar -- looks like it is very early in initialisaiton
[17:53] <secretlondon> hggdh, how do I get an strace of e-a-n?
[17:53] <secretlondon> hggdh, strace -Ff -tt evolution-alarm-notify 2>&1 | tee strace-e-a-n.log
[17:53] <secretlondon> strace: evolution-alarm-notify: command not found
[17:54] <secretlondon> ah I have it now
[17:58] <greg-g> btw, secretlondon, you're hardcore.
[17:58] <greg-g> secretlondon++
[17:58] <secretlondon> greg-g thanks
[17:59] <secretlondon> hggdh, only 2 polls, both unfinished
[18:00] <secretlondon> greg-g I have this bug 90% of reboots, it's annoying me somewhat..
[18:00] <ubotu> Bug 90 on http://launchpad.net/bugs/90 is private
[18:05] <greg-g> secretlondon: yeah, I guess if something were being that annoying I would be working that hard to resolve it too
[18:06] <secretlondon> greg-g also not everyone has it, so hggdh needs affected people
[18:06] <greg-g> right right
[18:07] <greg-g> either way, I applaud the effort
[18:07]  * greg-g claps
[18:07] <secretlondon> greg-g thanks!
[18:07] <greg-g> :)
=== dodger_ is now known as Hurt
=== Hurt is now known as Hurtz
[19:18] <Arby> update manager bugs - 8
[19:18] <Arby> only a few hundred more to go :)
[19:18] <greg-g> awesome
[19:19] <greg-g> thanks for the work Arby
[19:20] <Arby> yw
[19:21] <secretlondon> hggdh, any luck?
[20:27] <hggdh> secretlondon: sorry, was out for dinner
[20:28] <secretlondon> no problem!
[20:28] <hggdh> it really looks like an initialisation deadlock; what I do not understand is why only Ubuntu seems to suffer from this
[20:29] <hggdh> we should have other Evo users running & screaming around
[20:29] <hggdh> well
[20:29] <hggdh> gnome users, actually, since gnome uses the calendar functions from e-d-s
[20:30] <hggdh> I have sent it upstream, and will query there tomorrow evening (current contract does not allow me to get into IRC in the office)
[20:36] <secretlondon> hggdh cool, lets hope we get to the bottom of this
[20:36] <hggdh> yes... this has been going on for too long
[20:40] <secretlondon> hggdh, killing e-a-n also killes e-d-s though
[20:41] <hggdh> this is interesting
[20:41] <secretlondon> e-d-s then doesn't respawn until you run evo itself
[20:41] <hggdh> yes, that's expected
[20:41] <hggdh> e-a-n is started by the gnome session, and it should kick e-d-s in
[20:42] <secretlondon> and we know that e-d-s stops looping if it is killed, so killing e-a-n may just be that
[20:42] <hggdh> but I would not expect e-a-n to cause e-d-s to die. Will check on it right now
[20:43] <hggdh> hum. I killed my e-a-n, and e-d-s is still running
[20:43] <hggdh> the plot thickens
[20:43] <secretlondon> indeed
[20:44] <hggdh> but this is another good bit of information
[20:44] <hggdh> and I will mark upstream on it now
[20:45] <secretlondon> I should run an strace on the looping eds, i've run on the non looping one
[20:46] <secretlondon> gonna reboot to do that
[20:52] <secretlondon> hggdh, the strace of the looping eds is very different, lots of polling
[20:53] <hggdh> this seems to be one of the symptoms. the very fast poll() -- it seems the code is polling on no set channels
[20:54] <hggdh> the correct would be to sleep on poll() until an event happens, or a (larger) timeout kicks in
[20:54] <hggdh> if I remember correctly, the poll() is being driven ever 10**-4 seconds
[20:56] <hggdh> you still have it looping?
[20:56] <secretlondon> think killing strace has suspended it somehow
[20:56] <secretlondon> just uploaded the strace anyway
[20:57] <secretlondon> very different from nonlooping e-d-s, unlike the e-a-n ones which were similar
[20:59] <hggdh> e-d-s should (usually) be in a poll(), waiting for an event -- probably from a pipe, but certainly I/O
[20:59] <hggdh> then it gets a request and acts on it
[21:00] <hggdh> sometimes I think this is more a glib issue than evo
[21:00] <secretlondon> one of the threads is polling every .000070
[21:01] <hggdh> you can run sudo lsof -p `pidof evolution-data-server-2.22` | grep -v mem
[21:01] <hggdh> this is the loop
[21:03] <secretlondon> closing strace didn't bring eds's loop back, but then apport triggered
[21:03] <secretlondon> on eds, I'll let apport file the bug as may be interesting
[21:03] <hggdh> good idea
[21:03] <hggdh> refer to our dear bug in it
[21:03] <secretlondon> its on sig 5
[21:03] <hggdh> abort
[21:04] <hggdh> hum. memory issues?
[21:04] <secretlondon> I've run memtest on this laptop for 7 hours solid when I was getting random freezes
[21:04] <secretlondon> so I think the memory is okay
[21:06] <hggdh> sorry, I meant memory allocaiton
[21:06] <secretlondon> ah ok
[21:06] <hggdh> 5 is actually trap, not abrt
[21:08] <hggdh> and real memory errors would (hopefully) raise sigbus
[21:08] <secretlondon> hdddh bug #216936
[21:08] <ubotu> Bug 216936 on http://launchpad.net/bugs/216936 is private
[21:08] <secretlondon> evolution-data-server-2.22 crashed with signal 5 in __kernel_vsyscall()
[21:09] <hggdh> I will have to wait for apport to release it
[21:09] <secretlondon> sure
[21:09] <hggdh> sig 5 in __kernel_vsyscall??
[21:09] <secretlondon> yes
[21:09] <hggdh> ugh!
[21:10] <hggdh> this is a trap in the linux kernel
[21:10] <secretlondon> oh nice..
[21:10] <hggdh> :-)
[21:10] <hggdh> no boredom here
[21:14] <secretlondon> e-d-s seems to crash with sig 5 rather a lot..
[21:14] <secretlondon> no other ones on the kernel tho
[21:15] <hggdh> AFAIR the sig 5s were mostly on mallocs
[21:19] <hggdh> the stacktrace on bug 216936 does not show anything special
[21:20]  * secretlondon nods
[21:21] <hggdh> I will let it be, perhaps pedro_ or seb128 will think of something
[21:33] <hggdh> and... this is it, for me. I will hit the bed again. Thank you for your help, secretlondon.
[21:33] <secretlondon> hggdh, thanks for your help too, good night
[21:33] <hggdh> g'night
[21:36] <Tyrone> Hello everyone, can anyone help me out with a java bug I've found? I got it registered to launchpad, but it's not being looked at
[21:42] <Tyrone> hi, is anyone capable of helping out with a java bug?
=== Tyrone is now known as Tyrone__
=== _Czessi is now known as Czessi
[22:10] <greg-g> second opinion wanted: this bug has been fixed, but Launchpad Janitor only marked one of the projects as fixed.  Should I mark the other as Fixed Released to match or Invalid?  It is a splitting hairs question, I am just trying to clean up my bugs I am subscribed to.
[22:11] <greg-g> oh, this bug being bug 213745
[22:11] <ubotu> Launchpad bug 213745 in gnome-desktop "PDF pages appear extremely small in evince" [High,Fix released] https://launchpad.net/bugs/213745
[22:11] <alex-weej_> why is valgrind 38 MB?
[22:11] <alex-weej_> wth is in it that's that big?
[22:18] <secretlondon> greg-g if we fixed it, then i'd mark it as fixed
[22:22] <greg-g> secretlondon: yeah
[22:23] <greg-g> btw, if anyone sees sourcercito, they should tell them that due to the new work flow they should unassign themselves from bugs if they are not actively working on fixing it (ie: not just triaging the bug)
[22:24] <greg-g> I don't want to unassign sourcercito myself just in case
[22:39] <gfetco> Can someone help me with Pcsx2 Linux? I have it compiled and it is working but the plugins aint showing up I have BIOS also
[22:40] <secretlondon> gfetco, support is on #ubuntu
[22:40] <secretlondon> gfetco, or try launchpad answers
[22:40] <gfetco> launchpad?
[22:41] <gfetco> Sorry thought I was in #ubuntu
[23:07] <secretlondon> greg-g - sourcercito
[23:10] <greg-g> secretlondon: thanks
[23:11] <greg-g> sourcercito: I'm not sure if you know this or not, but the work flow for Launchpad bug triaging has changed.  Now you only assign yourself to a bug if you are actively working on fixing it.  If you are just triaging you only subscribe to the bug, not assign.  I am only saying this because I ran across a couple of bugs which you were assigned but it appears you are only triaging them.
[23:14] <sourcercito> hi there, greg-g i'll take a look a my old bugs, and update the info, thanks for the clarification ;)
[23:15] <greg-g> sourcercito: no problem. the change in work flow probably wasn't as widely announced as it could have been.
[23:17] <sourcercito> better this way though, i wasn't very comfortable assign them to me just to collect some info
[23:17] <greg-g> yeah, it is much cleaner now
[23:27] <greg-g> working fine in Hardy now, in the same angle that wasn't working before
[23:28] <greg-g> (base of laptop is at about a 45 degree angle with the horizon)