[00:51] <verb3k> There is a bug in Jaunty with unclear title, can someome help find a better one?  https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/359818
[00:54] <wnorrix> i keep getting a connection refused on ppa.launchpad.net when i try to upload my package
[00:54] <dtchen> 220 0.0.0.0 Canonical FTP server ready.
[00:54] <dtchen> seems fine from my route
[01:20] <NCommander> DO we have hardening wrapper installed by default on any architecture, or have all of its changes been merged into GCC spec files?
[01:40] <pwnguin> luisbg
[01:40] <pwnguin> doh
[03:02] <kees> slangasek: do you want me to upload the fix for linux86 (bug 360096)?
[03:45] <slangasek> kees: yes, please
[04:56] <poseidon> I found what I think might be a bug (could be handy in some situations).  When I have a browser open and it's playing music my music player (banshee, rythmbox etc) doesn't work.  I've tested this with opera, firefox, banshee, amarok, and rythmbox.  So I think that the problem is independent of the applications.
[04:56] <pwnguin> this is almost certainly flash's fault
[04:57] <poseidon> Well I am using the adobe version so I guess there isnt' anything we can do :(
[04:57] <pwnguin> yes / no
[04:57] <dtchen> it depends what audio backends are in use
[04:57] <pwnguin> theres stuff out there to sorta shim between flash and the newer audio stack
[04:58] <dtchen> as of intrepid, there is no need for flashplugin-nonfree-extrasound/libflashsupport
[04:59] <poseidon> I believe I just installed the flashplugin-nonfree package.  I don't know what kind of dependencies it uses
[04:59] <dtchen> if you're attempting to troubleshoot in jaunty, we should migrate to #ubuntu+1, otherwise (for a supported, stable Ubuntu release), #ubuntu
[05:00] <poseidon> I don't need any help.  Just wanted to let you guys know.
[05:01] <dtchen> we're aware (well, at least the audio team), and it's most likely a misconfiguration at the user end
[05:01] <dtchen> as of intrepid, installing Flash through adobe-flashplugin or flashplugin-nonfree does the right thing WRT pulse
[05:02] <dtchen> (obviously for Kubuntu, Xubuntu, Ubuntu Studio, etc., that don't seed PulseAudio, it's moot)
[05:02] <poseidon> I'm using a pretty default ubuntu interpid.
[05:03] <dtchen> default meaning with or without updates?
[05:03] <poseidon> with latest updates
[05:03] <dtchen> then it's already a resolved issue for jaunty
[05:04] <poseidon> k, cool :)
[10:43] <slangasek> asac: does ubufox need an update yet in order to point to the jaunty repo for plugins?  there's no pfs/db/sources.list.9.04, for instance
[10:45] <seb128> hey slangasek
[10:45]  * slangasek waves
[10:45] <seb128> slangasek: when do you expect we will be frozen frozen frozen for jaunty?
[10:46] <slangasek> seb128: next Monday, I hope
[10:46] <seb128> ok good, so still time to fix some bugs and send some GNOME 2.26.1 update your way ;-)
[10:50] <ogra> seb128, any idea why we have to use -O1 with the keyring daemon on ARM (thanks for including the fix though)
[10:53] <seb128> ogra: no
[10:53] <geser> doko: is there a common solution for FTBFS because the configure script sets the python script dir to "/usr/local/lib/python2.6/dist-packages"?
[10:55] <slangasek> the solution is to revert the latest python2.6 change
[10:57] <geser> this site-/dist-packages change seems to make much patching needed to get everything build correctly again
[10:58] <slangasek> generally, yes; but the specific problem you mention is a regression in python that's due to be reverted
[11:59] <slangasek> infinity: can you take care of a manual bootstrap of cup (bug #359743)?
[12:00] <infinity> slangasek: When I'm "at work" on Tuesday.
[12:01] <infinity> slangasek: Bonus points if you can remind me?
[12:01] <slangasek> infinity: ok. :) also, do we have a solution for P-a-s in place? (bg #301445)
[12:01] <infinity> slangasek: There's a branch that core-dev can commit to.
[12:02] <infinity> slangasek: (ie: feel free)
[12:02] <lamont> infinity: good to see  you're getting your sleep. :-p
[12:02] <infinity> lamont: Was at my parents' place all night upgrading a woody machine to hardy.  Shh.
[12:02] <infinity> "upgrading"... It was a rather violent affair.
[12:02] <lamont> woody?  zomg
[12:02] <slangasek> infinity: code.lp.net only lists one in cjwatson's namespace?
[12:03]  * lamont stabs at udev.  I hate trying to write new rules
[12:05] <slangasek> infinity: so where's the branch I can commit to? :/
[12:06] <infinity> slangasek: Remind me how to make bzr tell me where it's pulling a bound branch from? :P
[12:06] <slangasek> bzr info
[12:06] <slangasek> 'Checkout of...' or somethin
[12:06] <infinity>   checkout of branch: http://bazaar.launchpad.net/%7Eubuntu-core-dev/packages-arch-specific/ubuntu/
[12:06] <slangasek> curious; code.lp.net doesn't list that at all
[12:07] <infinity> slangasek: Anyhow, if you do commit changes that you expect to do anything useful, you'll want to poke cprov to run the queue-builder to pick up said changes.
[12:07] <slangasek> ok
[12:07] <infinity> slangasek: (Normally, I'd say any one of us could run queue-builder, but it's half-broken right now, and fails miserably without some handholding...)
[12:07] <infinity> \o/
[13:04] <maxb> Speaking of manual bootstrapping, cmucl (universe) is in more-or-less the same situation except it's been like that since warty or thereabouts. Is there some guideline on what should happen to packages like that?
[13:06] <persia> maxb, Ideally, make them not need manual bootstrapping :)
[13:06] <persia> Or find a way to bootstrap remotely through "limited" build, or similar.
[13:07] <IntuitiveNipple> When debugging multi-threaded apps, using gdb, is it possible to deduce which thread a function pointer is in by comparing its address to the gdb "info threads" list and looking at the Linux thread systags (which show addresses as far as I can tell) ?
[13:08] <maxb> and if no-one's got round to that since warty, who makes a call on when to kick the old binaries out of the archive?
[13:08] <broonie> IntuitiveNipple: A function pointer isn't in a thread.
[13:09] <persia> maxb, Anyone can file a removal bug, and any developer can approve it, although generally it's left for someone to fix later, especially if it's maintained in Debian.
[13:13] <IntuitiveNipple> broonie: Indeed, but I'm dealing with a structure with a request_handler * and the thread that was running the request_handler seems to be closing prematurely, so I'm trying to figure out how to get gdb to confirm that
[13:16] <broonie> IntuitiveNipple: Breakpoint in the function and step through it (or trace in the function)?
[13:18] <IntuitiveNipple> broonie: Hmmm, not sure that'll work since I can't identify (whilst the suspect thread is still active) which one it is, since I can only check the reference to it *after* it has gone AWOL!
[13:20] <IntuitiveNipple> broonie: It's a really convoluted AT-SPI >libORBit2 > atk-bridge  > java > eclipse issue
[13:24] <IntuitiveNipple> broonie: What I was hoping to trust is the gdb 'info threads' lists. I take one whilst the thread is alive, tell the app (eclipse) to close, it gets stuck, I take another thread list and find several have shutdown and one is stuck in a loop that surrounds a g_cond_timed)wait(), drill down into the data structures and try to figure out what is expected to be on the other end of the libORBit2 connection - the suspicion being the closed th
[13:24] <IntuitiveNipple> read that has yet to be finalized or GCed
[13:25] <slangasek> calc: if you're now waiting for revu for ooo-thumbnailer, should I be rejecting the package that's currently in the new queue?
[13:26] <IntuitiveNipple> broonie: If the thread systags represent the thread's base virtual address (which it appears to since each thread is a regular distance apart), I could maybe deduce which thread the request_handler was in
[16:09] <calc> slangasek: yea go ahead and reject it
[16:10] <calc> slangasek: i have a better packaged version now but not sure if anyone is going to look at it :\
[16:34] <calc> argh!
[16:35]  * calc kicks ooo packaging hard
[16:37] <calc> ooo-java-common managed to no longer pull in jre once we dropped the external saxon library :\
[16:38]  * calc has to upload a new OOo package now :\
[17:20] <gionnico> Someone stole me 80MB ! Help me finding him!
[17:21] <gionnico> Let's start with a dev question: does free -m show , under "used", also the memory used by the kernel itself?
[17:22] <directhex> calc, pfft, java casusing issues
[17:31] <calc> gionnico: i think that the kernel steals it off the top
[17:32] <gionnico> calc: ah, so ..
[17:33] <gionnico> is this ubuntu peculiarity?
[17:33] <gionnico> because in gentoo free -m and the sum of all processes matches exactly..
[17:34] <calc> gionnico: no
[17:34] <calc> gionnico: oh no i didn't explain properly
[17:34] <calc> gionnico: it steals it from "total" mem
[17:35] <gionnico> ah
[17:35] <calc> so the numbers should add up more or less i think
[17:35] <gionnico> ok so i still miss 80mb
[17:35] <gionnico> because free -m used shows me "X" while the sum of all processes makes "X-80"
[17:35] <calc> other thing steal from total also, like addressing on 32bit mode, etc
[17:35] <calc> s/mode/arch/
[17:35] <gionnico> well i don't really care if there's something i can't see
[17:36] <gionnico> but there's something i can see is using memory but i can't know what it is
[17:37] <gionnico> Can i?
[17:51] <radix> mathiaz: hi mathias, thanks very much for taking over that package upload on thursday
[17:51] <mathiaz> radix: you're welcome :)
[19:07] <radix> mathiaz: unfortunately, I'm going to have to dig myself into an even bigger karma debt and point out bug #360510
[19:07] <radix> huh
[19:08] <calc> crap i forgot to close the lp bug in my upload :\
[19:08] <radix> one sec, lemme fix that
[19:08] <radix> there's a core file in it, that's why it's private
[19:10] <radix> mathiaz: ok, bug #360510
[20:01] <calc> slangasek: can i get you to approve, ayaspell-dic, ifrench-gut, myspell-sv, and openoffice.org-dictionaries (I fixed all the remaining dictionaries)
[20:08] <lamont`> anybody looked into why xvnc4viewer barfs with "rect too big" on startup (regularly, sadly)
[20:10] <istaz_> maybe not the right place to ask this but anybody know if there is still a feisty mirror somewhere? I need it to install php5-gd on a server that I don't want to upgrade atm
[20:11] <Laney> old-releases.ubuntu.com
[20:12] <lamont`> istaz_: you do relize that feisty hasn't been getting security updates for a few months, yes?
[20:12] <istaz_> wow thanks you very much Laney exactl I needed
[20:13] <istaz_> lamont`: yes, I plan on upgrading it when Jaunty comes out
[20:14] <ScottK> calc: ifrench-gut accepted (it was in Universe).
[20:16] <calc> ScottK: thanks
[20:16] <calc> also i just uploaded the much better packaging version of ooo-thumbnailer (0.1~alpha2-0ubuntu1) if someone can accept that into universe, it's NEW
[20:19] <lamont`> istaz_: the transition from feisty->gutsy will be easier if you do it before gutsy gets EOLed over to old-releases.
[20:19] <lamont`> and by easier, I mean that edgy->feisty really really really sucked when I did it recently
[20:20] <istaz_> feisty -> gutsy then gutsy -> jaunty?
[20:20] <calc> istaz_: f -> g -> h -> i -> j
[20:21] <istaz_> wow this is going to take a long time ^^
[20:21] <calc> istaz_: he mans gutsy is going to be end of lifed later this week as well
[20:21] <calc> s/mans/means/
[20:22] <calc> istaz_: so better to do the upgrade before the packages get moved :)
[20:22] <istaz_> I don't really understand the point if I am going to upgrade right after upgrading to jaunty
[20:23] <istaz_> *gutsy
[20:23] <calc> istaz_: you can't skip releases for upgrades
[20:23] <calc> istaz_: unless you want to just reinstall
[20:24] <istaz_> ah I didn't know that
[20:24] <calc> istaz_: meaning you can't go from f -> j directly, you have to upgrade to each state in between for it to reliably upgrade
[20:24] <istaz_> ok
[20:24] <calc> istaz_: between LTS it is supported but not between regular releases, eg you can go from Dapper -> Hardy
[20:27] <jdstrand> ScottK: can you add the clamtk and klamav test case instructions to bug #360655, then subscribe ubuntu-sru when ready?
[20:28] <ScottK> jdstrand: Sure.
[20:28] <jdstrand> ScottK: thanks
[21:18] <directhex> if you were me, who would you file a bug against for a mouse sensitivity issue?
[21:21] <ScottK> lool: mobile-meta accpeted.
[21:23] <jcole> does mythbuntu jaunty have its own patched zenity that *does* steal focus? -> https://bugs.launchpad.net/ubuntu/+source/zenity/+bug/272083
[21:24] <ScottK> superm1: ^^
[21:26] <superm1> jcole, no, but the ideal situation is to have zenity grab focus.  as of right now, mythtv-setup doesn't work right for several situations because the zenity window is not focusing
[21:26] <superm1> and the application that spawned zenity is blocking, waiting on the user to answer the zenity question
[21:28] <pochu> directhex: xserver, but I'm not you :)
[21:30] <jcole> superm1: will mythbuntu have the proper glade config for zenity?
[21:31]  * jcole doesnt understand the rationale of having zenity windows default to be behind all other windows o_O
[21:31] <superm1> jcole, we're not going to change the zenity behavior for just mythbuntu, i'd prefer that we see it fixed in the distro
[21:32] <superm1> jcole, it's best to ask the #ubuntu-desktop folks why this is the way it is
[21:32] <superm1> I agree it sounds wrong right now
[21:32] <directhex> pochu, which source package is that?
[21:32] <NCommander> Can a buildd admin please kill the build on rhenium?
[21:34] <superm1> jcole, but if it comes down to it that the desktop team isn't willing to change that behavior, i suppose mythbuntu can ship a glade file and divert the one in zenity, but that's definitely not what i want to do
[21:34] <pochu> directhex: xorg
[21:34] <pochu> directhex: package is xserver-xorg
[21:34] <pochu> directhex: but I could be totally wrong. that's where I would fill it though :)
[21:36] <directhex> i think i might file against gnome-control-center since it's the customer-facing end of my issue
[21:36] <directhex> it can always be bounced around by a triager
[21:37] <directhex> oh. #
[21:37] <directhex> bug #28052
[21:38] <directhex> hm, no, not quite the issue i have
[21:48] <jcole> superm1: the main purpose of zenity *is* to steal focus... it's been like that for years... doesnt make sense to break all zenity apps for the sake of (whatever the rationale may be)
[21:49] <superm1> jcole, yeah i agree.  so tomorrow when everyone is back from holiday, it's a good idea to stir up this discussion
[21:54] <slangasek> calc: I'll have a look at those, sure
[21:56] <lool> ScottK: Thanks!
[22:10] <calc> slangasek: thanks
[22:11] <calc> slangasek: i also uploaded the better version of ooo-thumbnailer after going through REVU checks
[22:11]  * slangasek nods
[23:38] <LaserJock> bryce: regarding your email to -devel, I'm not sure what you mean by "performance problems". Do you mean "it'll make it go faster" or "it'll make it not crash as much"?
[23:41] <superm1> LaserJock, it will run more fluidly (faster)
[23:41] <LaserJock> hmm :/
[23:42] <LaserJock> I was hoping for the later
[23:42] <LaserJock> jaunty is certainly making me regret buying an Intel graphics card
[23:43] <ajmitch> LaserJock: the drivers are that bad?
[23:43] <calc> LaserJock: i think intel wanted to help prop up ati and nvidia a bit with their crappy drivers
[23:44] <calc> LaserJock: aiui their drivers on windows have been equally bad in other areas
[23:44]  * ajmitch might hold off on upgrading from hardy then
[23:44] <LaserJock> ajmitch: I get a lock-up about every day. I have to hard reboot.
[23:44] <ajmitch> that's pretty bad
[23:44] <lifeless> LaserJock: its 'not crash as much' too
[23:45] <calc> ajmitch: intrepid is probably fine, the main problem with intel drivers on jaunty are due to the 2.5/2.6 driver
[23:45] <lifeless> LaserJock: because you can stop using UXA
[23:45] <LaserJock> ajmitch: it's really spotty. you might be just fine, but this is the first Ubuntu release I've had problems
[23:45] <calc> ajmitch: https://wiki.ubuntu.com/X/Troubleshooting/IntelPerformance
[23:45] <dtchen> there are reports in the streets that newer libdrm and xserver-xorg-driver-intel are much more stable
[23:45] <dtchen> s/driver/video/
[23:45] <calc> dtchen: newer than what we have?
[23:45] <LaserJock> Intrepid was just fine for me
[23:46] <dtchen> calc: yes
[23:46] <calc> dtchen: ah
[23:46] <calc> bryce: ^ see what dtchen said (if you aren't already aware of it)
[23:46] <LaserJock> lifeless: does UXA currently fix problems?
[23:47] <lifeless> its the new vm for intel drivers, but AIUI its a little fragile right now
[23:47] <ScottK> LaserJock: UXA works great for me except when it falls over and dies.
[23:48] <jdong> performance and glitchiness are fine for me in UXA
[23:48] <jdong> just it frickin kills X on every resume
[23:48] <jdong> s/every/90%/
[23:48] <LaserJock> I don't care about like speed and stuff, I just want to be able to use FF without it having to hard-reboot every day
[23:48] <jdong> and EXA for me just hardlocks on compiz start.
[23:48] <LaserJock> s/it//
[23:49] <ScottK> LaserJock: The 'greedy' option described in Bug #359600 works great for me.
[23:49] <ScottK> Or in bryce's PPA....
[23:50] <LaserJock> ok, I'll give it a go
[23:50] <lifeless> LaserJock: disable compositing and UXA, use bryces deps, pretty sure it will be fine :)
[23:50] <LaserJock> lifeless: I've never used UXA, and I've tried without compositing. I'll now try bryces packages
[23:51] <ScottK> siretart was touting the newer Intel drivers yesterday or the day before.