[00:08] <slangasek> mdke: the ubuntu-docs intrepid-proposed upload includes changes to a number of files under libs/, and to scripts/fix-urls.sh and the serverguide, that aren't documented in the changelog; where do these come from?
[00:10] <kees> slangasek: hopefully I've now addressed your concerns in bug 275493
[00:11] <slangasek> kees: yep, thanks
[00:12] <kees> except I forgot to mark "evidence" to [3]
[01:09] <x1250> Hi, I'm trying to compile cinelerra, but I get a error about `/usr/lib/libogg.la' not being present or not being a valid libtool archive. Its not present, but libogg-dev is installed. I searched for it using apt-file and it was in the package, but then I updated my apt-file db, and bum! dissapeared. I tried creating a link with sudo ln -s /usr/lib/libogg.a /usr/lib/libogg.la, but make complains:
[01:09] <x1250> libtool: link: `/usr/lib/libogg.la' is not a valid libtool archive
[01:10] <x1250> so, how to fix this?
[01:22] <directhex> x1250, libtool files are generally to be avoided, as they're a cause of problems
[01:26] <x1250> someone had reported this and made a debdiff available: https://bugs.launchpad.net/ubuntu/+source/libogg/+bug/414362
[01:30] <directhex> cinelera is broken if it needs libtool archives
[01:40]  * james_w Wont-Fixed the bug
[01:40] <james_w> the libogg.la file was removed on purpose
[01:41] <james_w> cinelera should use an alternative method for linking with libogg
[01:42] <x1250> okay, I'll try to report this to the mantainers, if there is one... maybe lumiera is getting all the love now.
[01:42] <slangasek> james_w: if libtool is looking for it, it's because some other lib on the system which does have a .la file still references it and needs a rebuild
[01:42] <slangasek> (I grumbled at ron about the manner in which he got rid of libogg.la)
[01:42] <james_w> I uploaded the fix for one of them today
[01:42] <ion> Judging from past experience, cinelerra is broken, period. :-P
[01:49] <ScottK> Just because it's broken, doesn't mean it's the only thing that's broken.
[02:00] <slangasek> james_w: which one did you fix?  I've grabbed a list of the remaining revdeps referencing libogg.la
[02:01] <slangasek> according to my mirror currently
[02:12]  * slangasek batch-rebuilds the revdeps
[02:13]  * slangasek gets an itch to make dch --bin-nmu DTRT on Ubuntu
[02:20] <slangasek> oh, there's already a -R, alrighty then
[02:36] <MsMaco> *snort* people who dont know that "100 plus 3 percent" is different than "100 plus 3 percent of 100" complained til gcalctool started calculating 100+3%=103. now someone in #ubuntu is looking for a calculator that does it correctly and having to downgrade
[02:39] <lifeless> 3% of what
[02:40] <MsMaco> exactly
[02:40] <MsMaco> 3% on its own is 0.03
[02:42] <lifeless> no
[02:42] <lifeless> thats 3% of 1
[02:42] <slangasek> 3 per cent is 3 / 100
[02:42] <Pici> .03 * n will give you 3% of n
[02:43] <slangasek> but I don't see why anyone would ever type 100+3%
[02:43] <ojwb> it seems almost a "type mismatch" to me
[02:48] <MsMaco> specifying of what makes sense though
[02:49] <MsMaco> if you wanted to know how much eggs for $2 and $5 cereal thatsmarked at 25% off is... 2+75%*5
[03:00] <ojwb> sure, but there you've added units - $2 + 75%*$5 makes sense - $2 + 75% isn't in consistent units
[03:18] <MsMaco> ojwb: calculators tend not to have units
[03:19] <ojwb> um, sure
[03:19] <ojwb> that's kind of what I was getting at
[03:20] <emma> what kind of unit?
[03:20] <ojwb> there are usually implicit units
[03:21] <ojwb> any sort i guess
[03:21] <ojwb> units of measurement
[03:58] <EagleScreen> should debootstrap 1.0.15 from Debian unstable know about karmic release?
[04:07] <TheMuso> EagleScreen: I believe it does.
[04:08] <EagleScreen> it does not seem
[04:10] <EagleScreen> http://paste.ubuntu.com/254880/
[04:39] <Caesar> zul: pong
[04:45] <EagleScreen> i have this problem with pbuilder for any Ubuntu realease: http://paste.ubuntu.com/254892/
[04:46] <ipatrol> Hello?
[04:48] <EagleScreen> hello
[04:49] <ipatrol> I'm a Python enthusiast
[04:49] <ipatrol> How can I contribute?
[04:49] <EagleScreen> sure, Ubuntu develop many applications in python
[04:50] <ipatrol> Where can I start?
[04:52] <EagleScreen> ipatrol: go to #ubuntu-motu
[06:55] <dholbach> good morning
[08:38] <siretart`> morning folks
[08:39] <siretart`> mvo: I've redirected the question to the ubuntu-devel list. this issue is driving me mad...
[08:47] <mdke> slangasek: I'll check, sorry about that
[08:48] <YokoZar> Anyone else unable to use gpg-agent for signing packages in Karmic?  It's been broken for me for a while but I'm wondering if I just configured it wrong
[08:48] <mdke> slangasek: in the meantime perhaps you can reject the upload and I'll reupload with a better changelog
[09:08] <nh2> hi, I want to code some options for the touchpad settings
[09:08] <nh2> the touchpad settings tab sets the options in gconf, but how do the drivers get that information?
[09:25] <nh2> tseliot: are you here?
[09:32] <dholbach> gilir: do you think you can use the -v<version> option for debuild when you're uploading merges?
[09:40] <tseliot> nh2: yep
[09:43] <nh2> tseliot: I'd like to try to create two options for that right and middle click touchpad corner tapping thing, but I have no idea how the driver gets that information after the GUI has written it to gconf
[09:44] <tseliot> nh2: I'm working on a UI for touchpads. That will allow you to modify such details
[09:45] <gilir> dholbach: ok
[09:46]  * dholbach hugs gilir
[09:46] <nh2> tseliot: great! the gnome settings are indeed very plain. but will that be ready before the karmic release?
[09:46] <dholbach> gilir: always interesting to know what was merged and what happened in Debian :)
[09:47] <tseliot> nh2: I don't think so but I'll make it available in a PPA
[09:47] <gilir> dholbach: sure, but I didn't know this command :)
[09:48] <dholbach> ah ok, no worries :)
[09:49] <nh2> tseliot: OK. but it's still interesting for me how it is done now with that touchpad tab. eg. when I click "disable touchpad while typing", a value is written into gconf. but where is the place that value is read and submitted to the driver?
[09:49] <tseliot> nh2: that's in the gnome-settings-daemon
[09:51] <nh2> tseliot: ah ok, thanks, I'll have a look at it
[09:51] <tseliot> np
[10:24] <tseliot> mpt: ping
[10:27] <tseliot> mpt: I'd like to discuss bug 386017 with you
[10:32] <StevenK> james_w: You know that platform.karmic's desktop-common seed lists ttf-bitstream-vera, which you removed yesterday?
[10:32] <james_w> oops
[10:32] <james_w> ttf-dejavu is the replacement apparently
[10:35] <james_w> it looks like removing it was the wrong thing to do though, there is no transitional package, should I re-instate it?
[10:35] <tseliot> StevenK: would my upload of nvidia be rejected if I used version 185.18.31-0ubuntu1? Or should I bump the version and/or the revision?
[10:35] <mpt> tseliot, reading it now
[10:35] <tseliot> thanks
[10:36] <StevenK> james_w: If ttf-dejavu is the replacement, then I have a diff to the seeds, which I'll commit, and re-spin {ubuntu,unr}-meta.
[10:36] <StevenK> tseliot: And what is the source package name?
[10:36] <tseliot> StevenK: nvidia-graphics-drivers-180
[10:37] <StevenK> tseliot: Okay, and have the binary package names changed?
[10:37] <james_w> StevenK: not sure if it would be ttf-dejavu or ttf-dejavu-core actually
[10:37] <tseliot> StevenK: yep
[10:39] <james_w> e.g. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528152
[10:42] <mpt> tseliot, so there needs to be a setting for touchpads that have two or fewer buttons, determining whether middle-click is (a) left+right click together (if they have two buttons), (b) top right click, (c) bottom right click, (d) bottom left click, (e) top left click, or (f) nothing?
[10:42] <mpt> tseliot, while I remember, I'll e-mail you now the design stuff I've done so far for the touchpad settings -- sorry it's taken so long, it's not on my official to-do list
[10:43] <tseliot> mpt: first of all, thanks a lot for your work :-)
[10:44] <tseliot> mpt: yes, exactly
[10:44] <Ng> mpt: does the design include a "disable this touchpad" type setting? that disappeared so far in karmic
[10:45] <mpt> Ng, no, I understood that had been removed on purpose
[10:46] <Ng> mpt: I'm sure it was, and I'm sure I subjectively disagree with it because I hate my touchpad ;)
[10:47] <mpt> It would be nice to have an "Ignore touchpad whenever a mouse is connected" checkbox
[10:47] <Nafallo> Ng: your BIOS doesn't let you disable it?
[10:47] <mpt> but tseliot told me it's difficult for Ubuntu to tell when a mouse is connected (more difficult than for Mac OS X, apparently)
[10:47] <Ng> Nafallo: that hurts guest users, they get all confused when the big touchy mouse thing doesn't work
[10:48] <Ng> mpt: I'm only mildly familiar with xinput stuff, so I'm prepared to believe that, but I think a well designed preferences UI could mitigate the dire situation where someone disables their ownly mouse-like input
[10:48] <tseliot> mpt: the problem is that I can detect when an input device is connected. The input device might be, say, a wacom tablet and not a mouse
[10:49] <Ng> -w
[10:49] <tseliot> mpt: but if it's okay to disable the touchpad in that case, then it's not a problem for me to implement that feature
[10:49] <mpt> tseliot, couldn't you do that by a process of elimination? If it doesn't look like a touchpad, and it doesn't look like a tablet, it's probably a mouse
[10:49] <mpt> or something like that
[10:50] <tseliot> mpt: I think I can come up with something
[10:51] <Ng> afair older thinkpads serve the "nipple" mouse and touchpad via the same ps2 device and disabling the touchpad can disable the buttons of the nipple mouse, so I'd always envisaged a dialog that asks you to click to confirm after you disable a device, with a counter that re-enables it if you fail to click
[10:51] <Ng> but anyway
[10:52] <liw> . o O (there is no way to win, unless you control _everything_, which explains Apple)
[10:53] <tseliot> Ng: do you own a thinkpad with the nipple? It would be nice to see how xinput detects it
[10:53] <tseliot> liw: heh, we can fix things though ;)
[10:53] <liw> tseliot, I have one, lots of others do as well, so if you give instructions on what you need, I'm sure you'll get co-operation
[10:55] <tseliot> liw: perfect, thanks. For starters the output of "xinput list" and of "xinput list-props $THE_NIPPLE_NAME" should be enough
[10:55] <liw> tseliot, do you need this done under karmic or is jaunty enough?
[10:55] <Ng> tseliot: I have an X300 in front of me, and an X40 at home, I also work with a lot of other thinkpad users
[10:55] <tseliot> either karmic or jaunty should be fine
[10:56] <tseliot> good
[10:56] <liw> what is $THE_NIPPLE_NAME? (five minutes ago I didn't know xinput exist)
[10:57] <Ng> tseliot: http://pastebin.com/f49f35640, http://pastebin.com/f22cceb97, although the settings are slightly altered by my having run this script: http://pastebin.com/f7892bca4
[10:57] <liw> seomthing like this, I guess: TPPS/2 IBM TrackPoint
[10:57] <tseliot> liw: "xinput list --short" will give a list with the names of all your input devices
[10:58] <liw> tseliot, http://pastebin.ubuntu.com/255024/ and http://pastebin.ubuntu.com/255025/ -- that good enough?
[10:58] <Ng> duh, this is an X301, not a 300
[10:59] <tseliot> Ng, liw: thanks a lot
[10:59] <liw> tseliot, and I am using a thinkpad x200s, if that's important
[10:59] <Ng> tseliot: I'll try to remember to get you similar output from an X40 tonight if you would like?
[11:00] <tseliot> liw: good to know, thanks
[11:00] <ogra> Riddell, youre the archive admin of the day ? there is a linux-mvl-dove package in NEW the mobile team would appreciate to get building
[11:00] <tseliot> Ng: the more, the better ;)
[11:00] <Ng> :)
[11:00] <liw> . o O (it'd be sorta cool if there was one command that would make a report that has _all_ that kind of stuff, for easy perusal, stored in a database somewhere)
[11:00] <liw> . o O (wait, don't we have that?)
[11:02] <mpt> tseliot, https://wiki.ubuntu.com/TouchpadSettings
[11:02] <tseliot> mpt: as you can see (and I hadn't noticed), in Karmic we have access to the type of input device. Nipples and mice are detected as mice while touchpads are detected as touchpads
[11:03] <tseliot> liw: I could write that
[11:03] <liw> what's the PC word for the thinkpad-style non-touchpad device?
[11:03] <Ng> liw: trackpoint
[11:04] <Ng> at least that's what ibm/lenovo brand it
[11:04] <liw> Np, that's the ibm/lenovo name, I think, hmm
[11:04] <liw> wikipedia redirects to "Pointing stick"
[11:04] <directhex> nipple
[11:04] <tseliot> mpt: that looks great :-)
[11:04] <directhex> i think there's an xcd for this
[11:04] <directhex> xkcd
[11:05] <Ng> "pointing stick" is a pretty poor name. which kind of stick doesn't point? ;)
[11:05] <liw> it doesn't even look like a stick
[11:08] <tseliot> mpt: the left pane has a (vertical) scrollbar, doesn't it?
[11:08] <mpt> tseliot, I'm not sure yet whether it will need one
[11:08] <tseliot> the name "TrackPoint" should be enough for me to filter it out (As it can't be unplugged)
[11:09] <mpt> tseliot, it depends on the number of categories + the maximum number of subcategories (because only one category would be expanded at a time) vs. the maximum height of a single pane's settings
[11:09] <ogra> mpt, "pressure of last touch" should be "pressure of last tap" under the "minimum pressure to register a tap"
[11:10] <mpt> ogra, whether the touch counts as a tap is precisely what you're configuring :-)
[11:11] <ogra> on the left you configure touching for movement, on the right you configure tapping ... calling it tap on the right seems more consistent
[11:11] <mpt> though maybe it doesn't make sense to refer to the "last touch" if it's hard to distinguish zero from non-zero touch pressure
[11:12] <mpt> ogra, yes, the one on the left is for moving the pointer as opposed to clicking
[11:12] <Riddell> ogra: ok
[11:12] <tseliot>  mpt: ah, ok. Are you sure I shouldn't start implementing that?
[11:13] <mpt> The minimum pressure needed to touch for moving is a different setting from the minimum pressure needed to tap for clicking, aiui
[11:13] <ogra> Riddell, hold back, i think we want someone like cjwatson or slangasek to review it, i just looked at the naming of the headers packages and it doesnt seem right
[11:13] <mpt> tseliot, if you can get it done for Karmic, you could implement the one labelled "Version 1" on p3
[11:14] <ogra> Riddell, afaik there are some tools that expect it to be linux-headers-2*
[11:14] <mpt> tseliot, because it's a clean subset of the rest of the interface
[11:15] <mpt> (well, nearly clean)
[11:16] <tseliot> mpt: ok, does the Secondary click include corner tapping (top left, etc.) or did you remove those lines in the draft?
[11:18] <mpt> tseliot, I was considering not exposing the corner options at all, but I'm not sure about that, and Scott Ritchie's comment in bug 386017 is making me reconsider :-)
[11:20] <tseliot> mpt: let's experiment a bit then
[11:20] <mpt> Since it's just adding four(?) more options to a menu that's there anyway and would otherwise have only 2~3 options, I guess it would be worth it
[11:21] <tseliot> mpt: would it be possible to add middle click below secondary click?
[11:22] <tseliot> (disabled by default)
[11:22] <mpt> probably
[11:22] <tseliot> ok, good
[11:23] <mpt> and if the touchpad already has more than one button, I guess the secondary click setting should be replaced by a left-handed vs. right-handed setting
[11:23] <mpt> and similarly if the touchpad has more than two buttons, the middle-click setting needn't appear
[11:24] <tseliot> how would the left-handed vs. right-handed setting work?
[11:26] <tseliot> mpt: also, couldn't we let users decide whether to use buttons on corner tapping for right clicks or middle clicks?
[11:28] <mpt> tseliot, it would determine whether (L) the right button was primary and the left button was secondary, or (R) the left button was primary and the right button was secondary
[11:28] <mpt> but I see now there's no such option in the man page
[11:29] <mpt> maybe that's not as useful for touchpads as it is for mice? I have no idea
[11:29]  * mpt is left-handed but uses right hand for mouse and touchpad
[11:29] <tseliot> ah, ok. I'm right handed ;)
[11:30] <mpt> tseliot, I don't understand the difference between that question and what we were talking about 15 minutes earlier
[11:30] <mpt> so, we could add the corner options to the menus for both secondary and middle click
[11:30] <mpt> the only tricky design detail of that is how to prevent conflicts
[11:31] <mjr> could someone clarify if the latest jaunty kernel update contains the recent local root fix (a lot of stuff in the changelog, and the package is not in -security...)?
[11:31]  * mpt -> lunch
[11:32] <tseliot> mpt: If I understood correctly, you said that we should hide those settings when the buttons are available
[11:40] <nh2> tseliot: I haven't understood how the driver gets informed yet. The user makes the settings in the GUI. The GUI sets the gconf registry keys and gconf-daemon is informed. Now gconf-daemon has to inform the driver. But how does gconf-daemon know who to inform?
[11:41] <tseliot> nh2: the gnome-settings-daemon sets the property through Xinput and save the settings in gconf so that, when a new session starts, it can read the saved settings from gconf and apply them again through Xinput
[11:43] <nh2> tseliot: but the settings daemon itself doesn't know who to inform, it just gives us the infrastructure, right? so gnome-mouse-properties has to tell the daemon to notify Xinput or how is that done
[11:45] <nh2> eg. if /desktop/gnome/peripherals/touchpad/disable_while_typing is set to true, the daemon sets that setting without knowing about that path or what to do with it
[11:46] <tseliot> nh2: the daemon has a function for that which deals with the driver through the Xinput protocol. Actually, in the case of disable_while_typing, it simply calls syndaemon
[11:49] <nh2> tseliot: ok, I've finally found that function
[12:35] <mpt> tseliot, correct
[12:36] <mpt> tseliot, on the assumption that using a dedicated secondary-click button is more convenient than tapping in a corner
 mpt: If I understood correctly, you said that we should hide those settings when the buttons are available
[12:46] <maxb> I find it far easier to cornertap than to left+right simultaneously click
[12:47] <mpt> maxb, right, so that setting would be present if the touchpad has <3 buttons
[12:48] <maxb> I don't think you should completely hide settings ever. Default them sensibly yes, but don't hide them
[12:49] <maxb> For instance, I'll cornertap to right click sometimes, because the physical buttons on the early AAOs suck
[12:49] <maxb> Besides, someone may habituate to using one set of settings across all of their devices
[12:49] <hyperair> cornertap never seems to work for me =\
[12:49] <maxb> I've learnt how to do it properly now
[12:50] <mpt> maxb, obviously I disagree. For example, all the settings for what touchpad buttons should do shouldn't be present if your computer doesn't have any touchpad buttons.
[12:51] <maxb> ok, fine, if the setting is completely useless, yes
[12:51] <maxb> But don't hide settings on the _assumption_ the user won't want them (e.g. cornertapping)
[13:18] <slytherin> if there is a wrong node created fro dvd drive, which package is problematic? udev or devicekit-disks?
[13:20] <directhex> i officially no longer understand who's in charge of what in device nodey land
[13:20] <ogra> directhex, the who is easy :) its either pitti or Keybuk :P
[13:21] <slytherin> ogra: perhaps he meant which package. :-)
[13:21] <ogra> indeed he did :)
[13:21] <ogra> i guess its udev though
[13:22] <ogra> devkit should only operate on top of the nodes
[13:23] <slytherin> Ok. I just hope my bug gets solved soon. :-)
[13:24] <ogra> what nodes do you see for your dvd ?
[13:24] <ogra> my laptop has dvd1 and dvdrw1
[13:24] <ogra> seems about right
[13:25] <slytherin> ogra: for dvd I see cdrom3 which is a link to sr1. For CD drive I see cdrom which is link to sr0.
[13:26] <Keybuk> slytherin: what's the bug?
[13:26] <ogra> likely that the kernel doesnt set a dvd capability right
[13:27] <slytherin> Keybuk: bug #414665
[13:27] <Keybuk> slytherin: attach output of "udevadm info -q all -n sr0"
[13:27] <tseliot> mpt, maxb: I always use corner tapping even though my touchpad has physical buttons
[13:27] <slytherin> Keybuk: I am not at home right now. Will do that when I go home.
[13:28] <mpt> tseliot, why?
[13:28] <Keybuk> slytherin: you have no /dev/dvd* symlinks at all?
[13:28] <tseliot> hyperair: maybe because of this bug? http://bugs.freedesktop.org/show_bug.cgi?id=23102
[13:28] <slytherin> Keybuk: None. It was surprising for me too.
[13:28] <Keybuk> slytherin: probably not a udev bug then; your drive is likely not identifying itself properly
[13:29] <tseliot> mpt: I find it quicker to tap as opposed to use another finger (or to move the same finger) to click
[13:29] <slytherin> Keybuk: I bought it (second hand) from a friend. Let me talk with the original owner.
[13:29] <Keybuk> slytherin: if those symlinks are missing, it's not exactly earth-ending
[13:29] <lesshaste> hi all
[13:30] <slytherin> Keybuk: May be it is causing problem with DVD playback in totem. I am not sure though. I need to check with other players.
[13:30] <Keybuk> slytherin: totem does not use them
[13:31] <slytherin> libdvdread seems to be using it, it complains about 'no /dev/dvd device'. But let me get with more information.
[13:32] <Keybuk> I don't think anyone has a /dev/dvd symlink anymore
[13:32] <Keybuk> it's probably /dev/dvd481 by now
[13:32]  * ogra has dvd1
[13:32] <Laney> lrwxrwxrwx 1 root root 3 2009-08-17 11:07 /dev/dvd -> sr0
[13:32] <mpt> tseliot, but if you're moving to the corner you have to move your finger anyway, right?
[13:34] <Keybuk> Laney: the "I only installed yesterday" crowd are exempt ;)
[13:35] <tseliot> mpt: right but the buttons make me move my fingers far below and this interrupts my workflow thus slowing me down. Weird but true (in my case)
[13:35] <mpt> tseliot, ok
[13:35] <Laney> Keybuk: I installed several years ago!
[13:36] <Keybuk> Laney: then given the number of non-backwards compatible changes to the way that persistent symlinks are created, I don't see how you can still have that without a trailing number ;)
[13:36] <Keybuk> unless you've been manually fixing it
[13:36] <Laney> no, not at all
[13:36] <Keybuk> aren't you lucky then ;)
[13:36] <hyperair> tseliot: no, my circular scrolling corner works
[13:37] <Laney> well, the drive itself is shagged
[13:37] <Laney> so it's pretty useless to have it :(
[13:37] <Keybuk> there should be a symlink for that!
[13:37] <Keybuk> /dev/kaput -> sr0
[13:38] <tseliot> hyperair: what happens then? Can you file a bug report about it, please?
[13:39] <hyperair> tseliot: wait, i just tried and it works intermittently.
[13:39] <hyperair> tseliot: but i can't trigger it consistently
[13:39] <jdstrand> kirkland: so my little fix for bug #414986 didn't work. I didn't read the script carefully enough and my testing was in a chroot that didn't expose the bug :(
[13:39] <kirkland> jdstrand: yeah, bummer, i saw that
[13:40] <tseliot> hyperair: ok, it's still worth filing a bug about it though ;)
[13:40] <jdstrand> kirkland: I put my findings in the bug, but I don't feel comfortable making the change that I think is needed, cause I don't know open-iscsi at all
[13:40] <hyperair> tseliot: no wait, it seems like i can trigger it consistently now, but there's a lag of ~0.5-0.7s
[13:40] <hyperair> tseliot: basically i have to tap, and then wait for a response
[13:40] <kirkland> jdstrand: don't you think we should have an open-iscsi-dev package, that provides the stuff to be built against, but doesn't try to start any targets or anything?
[13:41] <tseliot> hyperair: does this happen irrespectively of the window you're tapping on? e.g. firefox, the desktop, etc.
[13:41] <hyperair> tseliot: yes
[13:41] <jdstrand> kirkland: that could work too-- it would need to provide iscsiadm in the case of libvirt
[13:42] <tseliot> hyperair: it's a bug then
[13:42] <hyperair> tseliot: hmm not misconfiguration?
[13:42] <hyperair> tseliot: is there any synclient setting i could try tweaking?
[13:42] <jdstrand> kirkland: so -dev might not be the best name for it
[13:42] <jdstrand> kirkland: maybe -tools?
[13:42] <kirkland> jdstrand: sure, fair enough
[13:43] <jdstrand> kirkland: and open-iscsi pulls in open-iscsi-tools?
[13:43] <kirkland> jdstrand: the key is for it *not* to have an init script
[13:43] <kirkland> jdstrand: right
[13:43] <hyperair> tseliot: ah, it seems that turning on FastTaps improves it
[13:44] <tseliot> hyperair: but doesn't that alter normal (i.e. non-corner) tapping?
[13:44] <jdstrand> kirkland: is that something you plan to do?
[13:44] <kirkland> jdstrand: i can do it if you need me to; i had other plans for my day, though :-)
[13:45] <kirkland> jdstrand: what else needs to be in there besides iscsiadm ?
[13:45] <jdstrand> I did too... all I want is libvirt to build, I didn't ask to get in the open-iscsi quagmire...
[13:45] <jdstrand> :)
[13:45] <kirkland> jdstrand: :-D
[13:45] <tseliot> hyperair: I meant double tapping
[13:46] <kirkland> jdstrand: okay, give me what needs to be moved from open-iscsi to open-iscsi-tools
[13:46] <kirkland> jdstrand: i'll build/test/upload, you can review and accept
[13:46] <jdstrand> kirkland: I really have no idea. like I said I don't know open-iscsi at all.... I don't know how to test it or use it
[13:47] <jdstrand> kirkland: well, for the time being I worked around it for my libvirt package by building with --without-storage-iscsi
[13:47] <jdstrand> kirkland: I think this is ok for my ppa
[13:47] <kirkland> jdstrand: right; i had to do the same for my hardy backport of libvirt, similar reasons
[13:48] <jdstrand> kirkland: it appears libvirt will build on an official buildd
[13:48] <sistpoty|work> jdstrand, kirkland: maybe open-iscsi should simply not fail in the mainter script if the invoke-rc.d fails?
[13:48] <hyperair> tseliot: yes it does. basically it reacts slower than a button tap, and so it confuses me =\
[13:49] <hyperair> tseliot: and sometimes, presumably because i didn't tap near enough to the corner, it doesn't respond.
[13:49] <jdstrand> kirkland: so, perhaps this can be pushed back past FF or at least until we are forced to fix it again (that way you can work on whatever you need to today)
[13:49]  * sebner waves at sistpoty|work :D
[13:49] <sistpoty|work> huhu sebner
[13:49] <hyperair> tseliot: basically i find it very unreliable and not a replacement for the clicking of touchpad buttons
[13:49] <jdstrand> sistpoty|work: I thought of that too, but wasn't comfortable making the change
[13:49] <jdstrand> kirkland: what do you think? ^ (of both)
[13:50] <tseliot> hyperair: I agree but it depends on the touchpad model
[13:50] <sistpoty|work> (a cleaner approach is always preferrable though than my suggestion ;)
[13:50] <hyperair> tseliot: perhaps. my touchpad's an alps model
[13:50] <kirkland> jdstrand: fedora has iscsi-initiator-utils
[13:50] <hyperair> tseliot: all the fancy multi-finger options fail.
[13:51] <tseliot> hyperair: I don't own alps touchpads but similar problems can take place with synaptics too
[13:51] <tseliot> hyperair: that depends on the fact that the touchpad doesn't support multi-touch and emulates it
[13:51] <tseliot> (badly)
[13:51] <hyperair> tseliot: another thing about the corner tapping is that without looking, you have to be very familiar with where the corner is, or you'll tap the wrong spot and end up triggering button1 (if you didn't disable it like i did).
[13:52] <hyperair> tseliot: my corner works nicely with circular scrolling because i actually slide my finger from off the touchpad onto the touchpad where the corner is
[13:52] <tseliot> hyperair: it's a matter of taste too
[13:53] <hyperair> tseliot: agreed, and it also depends on how well your touchpad buttons are designed. some are really a pain to press.
[13:53]  * tseliot nods
[13:53] <hyperair> tseliot: mine are nice and quiet, and also if you press the centre, you will nicely trigger both buttons.
[13:53] <jdstrand> kirkland: so you can do it today, we can wait or I can change the initscript to not return error. opinion?
[13:54] <kirkland> jdstrand: i'm hacking on it now
[13:54] <gilligan_> could any developer here sponsor/give me some hints on how to work on https://bugs.launchpad.net/ubuntu/+bug/413989  ?
[13:54] <kirkland> jdstrand: as far as I can tell, it only needs iscsiadm in there, looking at the libvirt code
[13:54]  * jdstrand feels somewhat guilty about making kirkland feel he had to do it *now*
[13:54] <kirkland> jdstrand: if i give you an iscsi source package, can you test it in your pbuilder?
[13:54] <kirkland> jdstrand: :-)  no worries, i walked right into this one....
[13:54] <jdstrand> kirkland: oh yes, I can test
[13:55] <kirkland> jdstrand: what's the bug # for the changelog?
[14:01] <jdstrand> kirkland: afaics, iscsiadm is all that is needed by libvirt. maybe look in iscsi-initiator-utils to see what else they put in there? (at a minimum, it will need to be whatever iscsiadm needs)
[14:01] <kirkland> jdstrand: okay
[14:01] <jdstrand> kirkland: 414986
[14:01] <kirkland> jdstrand: thanks
[14:01] <kirkland> jdstrand: i'm tweaking it now
[14:02] <jdstrand> kirkland: it might just be easier to put everything in open-iscsi-tools (or whatever), except the initscript and config files on used by the initscript. anyhoo, I'll let you judge how to best do it since you know more about it than I do :)
[14:06] <kirkland> jdstrand: hmm, okay, i having trouble with something simple here
[14:06] <kirkland> jdstrand: i have /sbin/iscsiadm in a new open-iscsi-utils package
[14:07] <kirkland> jdstrand: how do i exclude it from the open-iscsi package?
[14:07]  * jdstrand looks at the packaging
[14:08] <jdstrand> kirkland: so in debian/rules, we have:
[14:08] <jdstrand> install -m 755 usr/iscsiadm $(CURDIR)/debian/open-iscsi/sbin
[14:09] <jdstrand> kirkland: that should simply be changed to:
[14:09] <kirkland> jdstrand: duh!
[14:09] <jdstrand> install -m 755 usr/iscsiadm $(CURDIR)/debian/open-iscsi-tools/sbin
[14:09] <kirkland> jdstrand: okay, sorry
[14:09] <kirkland> jdstrand: sorry, i created an open-iscsi-utils.install file
[14:10] <jdstrand> ah, yes. well should work too, but you'd have to adjust debian/rules regardless
[14:10] <kirkland> jdstrand: and was looking for the same,
[14:10] <kirkland> jdstrand: okay, i'm moving it, and the manpage
[14:13] <kirkland> jdstrand: http://pastebin.ubuntu.com/255112/
[14:13] <kirkland> jdstrand: give that a go
[14:14] <kirkland> jdstrand: http://pastebin.ubuntu.com/255113/
[14:15] <jdstrand> kirkland: will iscsiadm work ok without things like iscsi-iname and iscsi_discovery? what about iscsid.conf?
[14:16]  * jdstrand again, has no idea :)
[14:16] <kirkland> jdstrand: i don't know ...  i was able to install it alone, and run it, and get the usage statement
[14:17] <jdstrand> kirkland: ok. I'll take a look at it here
[14:17] <kirkland> jdstrand: if this doesn't work for you, i'll do the inverse, and make another package with just the init script, dependent on the other one
[14:18] <jdstrand> it looks like it should work just fine, I just wanted to make sure that iscsiadm would work ok on its own
[14:25] <kirkland> jdstrand: well, that's sort of why i proposed calling this a -dev package, as those rarely provide standalone execute functionality
[14:37] <Laney> jcastro: Do you know if the videotaped UDS sessions are going to make it online? (non-plenary)
[14:38] <mok0> I'm looking for an example of someone maintaining packaging in a bzr branch.
[14:38] <mok0> Something that's properly split into an "upstream" and an "ubuntu" branch
[14:40] <tseliot> superm1: what's the status of DKMS flushing stdout?
[14:42] <superm1> tseliot, still need to see what it does on RHEL/F11.  been working out a whole lot of other things with DKMS first
[14:43] <tseliot> superm1: ok
[14:46] <jdstrand> kirkland: configure:    iSCSI: yes
[14:47] <jdstrand> kirkland: I think it is fine to upload. I checked iscsiadm.c and it doesn't seem to exec any of the other binaries
[14:47] <kirkland> jdstrand: yeah, i grepped through there
[14:47] <jdstrand> if it does need something, it is easy enough to change later
[14:47] <kirkland> jdstrand: ack
[14:47] <kirkland> jdstrand: did your libvirt build?
[14:48] <jdstrand> kirkland: that was the 'configure:    iSCSI: yes' I mentioned
[14:49] <kirkland> jdstrand: ah, okay
[14:49] <kirkland> jdstrand: i'm uploading then
[14:49] <kirkland> jdstrand: cool?
[14:49] <jdstrand> kirkland: yeah, go for it
[14:49] <jdstrand> kirkland: thanks :)
[14:50] <kirkland> jdstrand: done ;-)  you're welcome :-)
[15:03] <liw> what's the correct way to print to stdout some unicode text in python? or should I just use u.encode('utf-8')?
[15:04] <liw> (i.e., assume utf-8 is the local charset, other charsets be damned?)
[15:23] <tseliot> liw: "Wrapping sys.stdout into an instance of StreamWriter will allow writing unicode data with sys.stdout.write() and print": http://wiki.python.org/moin/PrintFails
[15:42] <liw> tseliot, my problem is not related to the print statement, actually, but in taking a string and converting it to an encoding in the user's preferred charset
[15:42] <liw> but I'm going to stick to utf-8 until someone complains
[15:42] <tseliot> liw: what program would that be for?
[15:43] <liw> does it matte?
[15:43] <Laney> james_w: If I call debcommit from a branch which I've made following https://wiki.ubuntu.com/DistributedDevelopment/Documentation/GettingTheSource then I get a "readonly transport" error
[15:44] <james_w> Laney: yeah, you're the second person to trip over that
[15:44] <james_w> https://wiki.ubuntu.com/DistributedDevelopment/Documentation/WorkingOnAPackage
[15:44] <Laney> oh
[15:44] <Laney> I need to branch?
[15:44] <james_w> perhaps I should switch it round so that GettingTheSource gets you a full branch
[15:44] <james_w> yeah
[15:45] <Laney> I thought that was optional, like for a topic-branch
[15:45] <james_w> the intent is that you always have a pristine copy of trunk, and then use feature branches
[15:45] <Laney> alright
[15:45] <james_w> yeah, it is optional, but it is good practice
[15:45] <james_w> the pristine copy is important for merging, but perhaps I should move it to be a step in the merging process
[15:46] <mathiaz> james_w: how about just a note in the GettingTheSource package that you should branch to work on an update?
[15:46] <Laney> I just think you need to emphasise that step more
[15:46] <james_w> mathiaz: that would be a good idea
[15:46] <mathiaz> james_w: Having a co of the package is good approach IMO.
[15:46] <james_w> it's two equally valid ways of working, it's just which makes more sense to people
[15:47] <mathiaz> james_w: OTOH once write access to the LP branch is available having a co instead of a branch may lead to unexpected commits
[15:47] <james_w> the other advantage of what Laney tried to do is that it is less steps until you get to the "vi ..." point of the process
[15:47] <Laney> I didn't expect debcommit to try and push anyway
[15:47] <james_w> mathiaz: true as well
[15:47] <Laney> so I would have made my changes, commited with debcommit
[15:47] <Laney> and then bzr push lp:~laney/...
[15:49] <Daviey> Is this using LP to pull in upstream SVN etc, or using rules get-orig-source ?
[15:49] <Laney> LP exposes packages as bzr branches now
[15:50]  * Daviey will leave his question for another time then :)
[15:50] <Laney> please don't
[15:51] <james_w> Daviey: these branches are built from unpacked source packages, so it uses whatever is in the .orig.tar.gz
[15:52] <james_w> we don't have anything that optimistically uses watch files/get-orig-source to try and merge new upstream versions or anything
[15:52] <Laney> james_w: Is there a proper way to do a merge? I'd like to preserve context if possible
[15:52] <james_w> and it's not attached to real upstream branches, which we intend to fix, but it is a big job
[15:52] <james_w> Laney: a merge of what?
[15:53] <Laney> from Debian
[15:53] <james_w> ah
[15:53] <james_w> "bzr merge lp:debian/sid/<package>" will work
[15:53] <Laney> sweet
[15:53] <james_w> however, if debian adds a new upstream version then you will get spurious conflicts :-/
[15:53] <Laney> it's a native package...
[15:53] <james_w> al-maisan is currently writing code to stop that from happening
[15:53] <james_w> no problem then
[15:54] <Laney> double sweet
[15:54] <al-maisan> heh :)
[15:54] <james_w> hi al-maisan :-)
[15:54] <tseliot> slangasek: ping
[15:54] <al-maisan> james_w: hello there :)
[15:55] <tseliot> liw: no, I was just curious
[15:56] <Daviey> james_w: Do we have a process to check debian/watch ?
[15:56] <Laney> hm
[15:57] <Laney> it missed out a Debian revision
[15:57] <james_w> Daviey: and do what?
[15:57] <james_w> report new upstream versions?
[15:57] <Daviey> jah
[15:57] <Laney> Daviey: http://qa.ubuntuwire.com/uehs/
[15:58] <james_w> http://qa.ubuntuwire.com/uehs/no_updated.html
[15:58] <Daviey> Ooo.. didn't know this.
[15:58] <Laney> and the corresponding Debian page for non ubuntu-specific packages
[15:58] <Daviey> sure.
[16:01] <james_w> Laney: what's the package that's causing trouble? I'd like to take a look
[16:03] <Laney> james_w: cdbs ;)
[16:03] <Laney> It's not really trouble, just a dropped revision when I merged from the sid branch
[16:04] <james_w> Does my https://wiki.ubuntu.com/DistributedDevelopment/Documentation/GettingTheSource edit help at all?
[16:05] <Laney> yeah
[16:06] <Laney> but I bet when these branches become read/write you see a lot of accidental pushes
[16:07] <Laney> is setting the sponsors as reviewer a part of the process?
[16:07] <james_w> yeah, unfortunately :-/
[16:07] <Laney> wiki page doesn't say this
[16:08] <james_w> there's no team for "people who can upload this package" that we can make it default to
[16:08] <james_w> I need to have the discussion again with LP people about how to make this work
[16:08] <james_w> thanks, fixing
[16:08] <james_w> Laney: which revision was dropped?
[16:08] <Laney> 0.4.57
[16:08] <james_w> ah
[16:08] <Laney> unless this wasn't ever uploaded
[16:09] <Laney> no, it was
[16:09] <james_w> it seems LP never mirrored it
[16:09] <Laney> think I've finished now
[16:10] <Laney> that was fun
[16:10] <Laney> spoiler I mainly did it to jump the sponsor queue
[16:10] <Laney> visions of being told to go away as it's too close to FF
[16:13] <james_w> so now you are going to make me review cdbs?
[16:13] <Laney> I was being a bit cheeky
[16:13] <Laney> of course I don't expect you to do that
[16:13] <Laney> happy to wait :)
[16:14] <Laney> Just edgy as pitti is off and it looks like he takes care of it here
[16:15] <james_w> well, I said it, so now I've got to do it :-)
[16:15] <james_w> I'll take a look, but I may defer
[16:16] <Laney> no worries
[16:16] <Laney> it's a scary package that I didn't particularly want to touch myself
[16:35] <ogra> evand, do you have any idea about the ubiquity FTBFS on armel ?
[16:35]  * ogra is wondering why the directory doesnt exist
[16:36] <ogra> sed 's/@VERSION@/1.99.7/g' bin/ubiquity \
[16:36] <ogra> 		> debian/ubiquity/usr/lib/ubiquity/bin/ubiquity
[16:36] <ogra> /bin/sh: cannot create debian/ubiquity/usr/lib/ubiquity/bin/ubiquity: Directory nonexistent
[16:36] <evand> hrm
[16:46] <james_w> Laney: which changes to the haskell packages rely on?
[16:46] <Laney> I see what you're thinking and I am half thinking the same
[16:46] <Laney> the one from 0.4.59
[16:49] <kees> does glib set free'd pointers to 0xaaaaaaaa ?
[16:50] <soren> kees: How?
[16:50] <soren> kees: Pointers are passed by value, aren't they?
[16:50] <james_w> ah, I recognise the name now
[16:50] <james_w> ubuntu->ubuntu diff looks ok to me
[16:50] <james_w> can't see much there that might trip things up
[16:51] <kees> soren: right, that's what I'm trying to understand.  I've seen a class of crashes from glib-linked code that deref 0xaaaaaaa+offset instead of NULL+offset, and I'm trying to figure out the source
[16:51] <Laney> I test built a whole bunch of packages
[16:51] <Laney> and didn't notice anything
[16:51] <kees> soren: e.g.: Bug 415295
[16:51] <james_w> nice
[16:51] <kees> gah
[16:51] <soren> kees: Not allowed.
[16:51] <kees> soren: one sec
[16:51] <soren> Sure.
[16:52] <kees> soren: I've sub'd you.  the retracer hasn't finished with it, so it's still private with the coredump
[16:52] <soren> kees: Right, I can see the bug now.
[16:52] <soren> Where do you see the 0xaaaaaaaa thing?
[16:52] <kees>  source "0x4(%eax)" (0xaaaaaaae) not located in a known VMA region (needed readable region)!
[16:53] <kees> soren: in the SegvAnalysis section
[16:53]  * soren glances around
[16:53] <soren> Oh, there!
[16:54] <kees> I wonder if it's for glib-controlled structures (here, glist)
[16:54]  * soren wonders if he can still find his way around glib code
[16:56] <Riddell> kirkland: classads accepted but bug 415454 has a wee issue
[16:57] <kirkland> Riddell: i'll fix that ASAP
[17:11] <slangasek> tseliot: hi
[17:12] <slangasek> mdke: ok, rejected
[17:12] <tseliot> slangasek: hey, do you mind if we discuss something in private?
[17:12] <slangasek> tseliot: no problem
[17:17] <niklas_> how to enable debugging symbols in a program so I can use it with gdb?
[17:17] <niklas_> I've enabled -g and -O0, but gdb still complains "no debugging symbols found"
[17:19] <evand> ogra: not sure, but I suspect it might be related to the work cjwatson did to move ubiquity to debhelper 7.  I'm poking at it.
[17:20] <ogra> thanks, i wouldnt know where to dig ... intresting that it only happens on port arches though
[17:21] <evand> indeed it is
[17:31] <ogra> slangasek, i know its not your archive day today, but a look at the linux-mvl-dove package in source NEW would be appreciated so tim knows what to change to have proper naming everyone is happy with (i personally think the naming of the header binaries will get us issues and tim is still working on the package)
[17:34] <tedst> hey
[17:34] <tedst> #hello room
[17:35] <tedst> hello room
[17:48] <NCommander> slangasek, I can help w/ that package if need be since I'm depwait on it for many things :-)
[18:57] <meta_> Hi folks
[18:58] <meta_> I have installed karmic koala to my eee 1000h, and after an upgrade&reboot i have no mouse cursor now
[18:58] <meta_> Now i'm from cli/irssi
[18:58] <meta_> If anybody have an idea how can i get back my rat, please tell me:)
[19:00] <Pici> meta_: This really isn't a support channel. Karmic discussion and support is in #ubuntu+1
[19:00] <meta_> oh sry
[19:00] <meta_> thank you
[19:30] <Laney> james_w: Thanks loads for the upload
[19:37] <mterry> What's the best way to regenerate an autoreconf.patch?  autoreconf -something -something?
[19:39] <Laney> -f -i -s
[19:39] <Laney> s'what I use
[19:40] <mterry> k, and then delete the autom4te.cache crap?
[19:43] <Laney> sounds good
[19:45] <hyperair> i use autoreconf -vfi
[19:46] <hyperair> rather, i put that in debian/rules
[19:46] <hyperair> the banshee-daily ppa packaging has an example
[19:47] <slangasek> hyperair: do you also remove the autogenerated files in debian/rules clean, so that there isn't a huge debdiff after every rebuild?
[19:47] <hyperair> slangasek: yes..
[19:47] <slangasek> hurray!
[19:47] <hyperair> find -name Makefile.in -delete
[19:58] <nh2> tseliot: how to print a simple trace of the functions called in gdb?
[19:58] <nh2> I'd like to know the way a program took to a certain line
[20:03] <chrisccoulson> mr_pouit - regarding bug 415525 - i'm not sure i understand the issue is currently
[20:04] <chrisccoulson> gnome-mount is completely deprecated now isn't it?
[20:08] <mr_pouit> chrisccoulson: I'm not sure how that works actually, but since there is explicit calls to gnome-mount…
[20:08] <chrisccoulson> mr_pouit - gnome-mount is not installed any more on ubuntu
[20:08] <chrisccoulson> it's only required with the deprecated HAL backend
[20:09] <chrisccoulson> you're using DK-disks / GDU on xubuntu aren't you?
[20:09] <mr_pouit> devicekit?
[20:10] <mr_pouit> no, thunar still rely on libhal-storage
[20:10] <chrisccoulson> well, devicekit-disks and gnome-disk-utility
[20:10] <chrisccoulson> hmmmmm
[20:10] <juliux> hi does somebody knwos what software is used for this schedule? http://summit.ubuntu.com/uds-karmic/
[20:10] <chrisccoulson> i might need to try a xubuntu install here and figure out how it works ;)
[20:11] <beuno> juliux, it's something Keybuk put together
[20:11] <beuno> not sure if there's source for it somewhere or not
[20:11] <juliux> beuno: thxs
[20:11] <juliux> Keybuk: is the source of http://summit.ubuntu.com/uds-karmic/ available?
[20:13] <beuno> juliux, looking on LP, I found: https://code.edge.launchpad.net/summit
[20:14] <beuno> juliux, https://code.edge.launchpad.net/~scott/summit/schedule
[20:14] <beuno> that seems to ahve the code
[20:16] <mr_pouit> chrisccoulson: okay, thanks. I'm trying to figure out as well, but I have to admit I'm a bit lost…
[20:17] <chrisccoulson> yeah, i'll see if i can figure it out too
[20:18] <chrisccoulson> but if you're doing the mounting via gio/gvfs, then all this should be transparent to thunar anyway
[20:18] <chrisccoulson> mr_pouit - could you post the output of "gvfs-mount -li" somewhere from your xubuntu machine?
[20:19] <chrisccoulson> (i'm just waiting for the ISO to download)
[20:21] <mr_pouit> chrisccoulson: I only have a debian unstable+xfce at hand at the moment, but here it is http://pastebin.ca/1534197
[20:21] <chrisccoulson> thanks
[20:22] <chrisccoulson> debian unstable is still using the HAL VolumeMonitor it seems though
[20:23] <chrisccoulson> i was just wondering if xubuntu is using the GDU VolumeMonitor instead - in which case, you don't need gnome-mount, as the mounting is all handled somewhere in libgdu
[20:29] <mr_pouit> chrisccoulson: http://paste.ubuntu.com/255328/
[20:29] <mr_pouit> it's from a vm, but it uses gdu apparently
[20:30] <mr_pouit> so this means the patch isn't needed?
[20:30] <chrisccoulson> mr_pouit - thats good - so there should be no need for gnome-mount
[20:30] <mr_pouit> okay, I'll mark the bug as invalid then, thanks
[20:31] <chrisccoulson> you're welcome
[20:55] <slangasek> superm1: hmm, why does libmyth now need all of Qt as a dep?
[21:00] <pgquiles> siretart: ping
[21:06] <lamont>  /var/lib/dpkg/info/libc6.postinst: 92: runlevel: not found
[21:06] <lamont> has that been reported yet, I wonder?
[21:07] <slangasek> not AFAIK
[21:09] <slangasek> lamont: I guess that's a jaunty->karmic upgrade, with a race condition on unpacking the new upstart packages
[21:10] <slangasek> because someone said upstart doesn't need to be Essential: yes :)
[21:10] <lamont> slangasek: jaunty->karmic in a chroot on a hardy box
[21:13] <slangasek> lamont: Debian doesn't have this problem because sysvinit is Essential: yes; I'd suggest filing the bug against upstart to do the same, and if Keybuk rejects that, we can make libc6 depend on upstart (pff)
[21:14] <lamont> lol
[21:14] <slangasek> lamont: do you have a log showing the state of all 'upstart*' packages at the time the error happened?
[21:14] <lamont> or at least notice that sometimes things aren't there..
[21:14] <lamont> slangasek: only if apt-get dist-upgrade will give me such a log.
[21:15] <slangasek> /var/log/apt/term.log :)
[21:15] <lamont> ta
[21:15] <slangasek> (unless you did it in a chroot with no ptys)
[21:15] <lamont> :-)
[21:44] <superm1> slangasek, it needs qt4 now, it used to need qt3
[21:45] <slangasek> superm1: ah, indeed
[21:48] <superm1> slangasek, is this a problem, or were you just curious..?
[23:11] <mathiaz> lamont: hey - does it make sense to sync postfix from unstable to karmic?
[23:11] <mathiaz> lamont: the mysql build dependency is included in unstable and there is a new upstream version
[23:38] <ccheney> OOo 3.1.1~rc1-1ubuntu1 will be uploaded in about 45m (staging atm)
[23:57] <TheMuso> c