=== robbiew is now known as robbiew_ === asac_ is now known as asac [00:08] 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] slangasek: hopefully I've now addressed your concerns in bug 275493 [00:10] Launchpad bug 275493 in glibc "stack protector guard value uses a static sentinel" [Medium,In progress] https://launchpad.net/bugs/275493 [00:11] kees: yep, thanks [00:12] except I forgot to mark "evidence" to [3] [01:09] 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] libtool: link: `/usr/lib/libogg.la' is not a valid libtool archive [01:10] so, how to fix this? [01:22] x1250, libtool files are generally to be avoided, as they're a cause of problems [01:26] someone had reported this and made a debdiff available: https://bugs.launchpad.net/ubuntu/+source/libogg/+bug/414362 [01:26] Ubuntu bug 414362 in libogg "/usr/lib/libogg.la missing in libogg-dev 1.1.4~dfsg-1" [Undecided,Confirmed] [01:30] cinelera is broken if it needs libtool archives [01:40] * james_w Wont-Fixed the bug [01:40] the libogg.la file was removed on purpose [01:41] cinelera should use an alternative method for linking with libogg [01:42] okay, I'll try to report this to the mantainers, if there is one... maybe lumiera is getting all the love now. [01:42] 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] (I grumbled at ron about the manner in which he got rid of libogg.la) [01:42] I uploaded the fix for one of them today [01:42] Judging from past experience, cinelerra is broken, period. :-P [01:49] Just because it's broken, doesn't mean it's the only thing that's broken. [02:00] james_w: which one did you fix? I've grabbed a list of the remaining revdeps referencing libogg.la [02:01] 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] oh, there's already a -R, alrighty then [02:36] *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] 3% of what [02:40] exactly [02:40] 3% on its own is 0.03 [02:42] no [02:42] thats 3% of 1 [02:42] 3 per cent is 3 / 100 [02:42] .03 * n will give you 3% of n [02:43] but I don't see why anyone would ever type 100+3% [02:43] it seems almost a "type mismatch" to me [02:48] specifying of what makes sense though [02:49] if you wanted to know how much eggs for $2 and $5 cereal thatsmarked at 25% off is... 2+75%*5 [03:00] sure, but there you've added units - $2 + 75%*$5 makes sense - $2 + 75% isn't in consistent units [03:18] ojwb: calculators tend not to have units [03:19] um, sure [03:19] that's kind of what I was getting at [03:20] what kind of unit? [03:20] there are usually implicit units [03:21] any sort i guess [03:21] units of measurement [03:58] should debootstrap 1.0.15 from Debian unstable know about karmic release? [04:07] EagleScreen: I believe it does. [04:08] it does not seem [04:10] http://paste.ubuntu.com/254880/ [04:39] zul: pong [04:45] i have this problem with pbuilder for any Ubuntu realease: http://paste.ubuntu.com/254892/ [04:46] Hello? [04:48] hello [04:49] I'm a Python enthusiast [04:49] How can I contribute? [04:49] sure, Ubuntu develop many applications in python [04:50] Where can I start? [04:52] ipatrol: go to #ubuntu-motu === crd1b is now known as crdlb [06:55] good morning === tkamppeter_ is now known as tkamppeter === crd1b is now known as crdlb === lionel_ is now known as lionel [08:38] morning folks [08:39] mvo: I've redirected the question to the ubuntu-devel list. this issue is driving me mad... [08:47] slangasek: I'll check, sorry about that [08:48] 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] slangasek: in the meantime perhaps you can reject the upload and I'll reupload with a better changelog [09:08] hi, I want to code some options for the touchpad settings [09:08] the touchpad settings tab sets the options in gconf, but how do the drivers get that information? [09:25] tseliot: are you here? [09:32] gilir: do you think you can use the -v option for debuild when you're uploading merges? [09:40] nh2: yep [09:43] 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] nh2: I'm working on a UI for touchpads. That will allow you to modify such details [09:45] dholbach: ok [09:46] * dholbach hugs gilir [09:46] tseliot: great! the gnome settings are indeed very plain. but will that be ready before the karmic release? [09:46] gilir: always interesting to know what was merged and what happened in Debian :) [09:47] nh2: I don't think so but I'll make it available in a PPA [09:47] dholbach: sure, but I didn't know this command :) [09:48] ah ok, no worries :) [09:49] 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] nh2: that's in the gnome-settings-daemon [09:51] tseliot: ah ok, thanks, I'll have a look at it [09:51] np [10:24] mpt: ping [10:27] mpt: I'd like to discuss bug 386017 with you [10:27] Launchpad bug 386017 in hundredpapercuts "Brushing right-edge of trackpad causes clipboard to paste text" [Undecided,Confirmed] https://launchpad.net/bugs/386017 [10:32] james_w: You know that platform.karmic's desktop-common seed lists ttf-bitstream-vera, which you removed yesterday? [10:32] oops [10:32] ttf-dejavu is the replacement apparently [10:35] it looks like removing it was the wrong thing to do though, there is no transitional package, should I re-instate it? [10:35] 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] tseliot, reading it now [10:35] thanks [10:36] 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] tseliot: And what is the source package name? [10:36] StevenK: nvidia-graphics-drivers-180 [10:37] tseliot: Okay, and have the binary package names changed? [10:37] StevenK: not sure if it would be ttf-dejavu or ttf-dejavu-core actually [10:37] StevenK: yep [10:39] e.g. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528152 [10:39] Debian bug 528152 in tulip "tulip: declares relation to ttf-bitstream-vera" [Important,Open] [10:42] 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] 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] mpt: first of all, thanks a lot for your work :-) [10:44] mpt: yes, exactly [10:44] mpt: does the design include a "disable this touchpad" type setting? that disappeared so far in karmic [10:45] Ng, no, I understood that had been removed on purpose [10:46] mpt: I'm sure it was, and I'm sure I subjectively disagree with it because I hate my touchpad ;) [10:47] It would be nice to have an "Ignore touchpad whenever a mouse is connected" checkbox [10:47] Ng: your BIOS doesn't let you disable it? [10:47] 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] Nafallo: that hurts guest users, they get all confused when the big touchy mouse thing doesn't work [10:48] 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] 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 === ember_ is now known as ember [10:49] -w [10:49] 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] 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] or something like that [10:50] mpt: I think I can come up with something [10:51] 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] but anyway [10:52] . o O (there is no way to win, unless you control _everything_, which explains Apple) [10:53] Ng: do you own a thinkpad with the nipple? It would be nice to see how xinput detects it [10:53] liw: heh, we can fix things though ;) [10:53] 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] liw: perfect, thanks. For starters the output of "xinput list" and of "xinput list-props $THE_NIPPLE_NAME" should be enough [10:55] tseliot, do you need this done under karmic or is jaunty enough? [10:55] 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] either karmic or jaunty should be fine [10:56] good [10:56] what is $THE_NIPPLE_NAME? (five minutes ago I didn't know xinput exist) [10:57] 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] seomthing like this, I guess: TPPS/2 IBM TrackPoint [10:57] liw: "xinput list --short" will give a list with the names of all your input devices [10:58] tseliot, http://pastebin.ubuntu.com/255024/ and http://pastebin.ubuntu.com/255025/ -- that good enough? [10:58] duh, this is an X301, not a 300 [10:59] Ng, liw: thanks a lot [10:59] tseliot, and I am using a thinkpad x200s, if that's important [10:59] tseliot: I'll try to remember to get you similar output from an X40 tonight if you would like? [11:00] liw: good to know, thanks [11:00] 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] Ng: the more, the better ;) [11:00] :) [11:00] . 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] . o O (wait, don't we have that?) [11:02] tseliot, https://wiki.ubuntu.com/TouchpadSettings [11:02] 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] liw: I could write that [11:03] what's the PC word for the thinkpad-style non-touchpad device? [11:03] liw: trackpoint [11:04] at least that's what ibm/lenovo brand it [11:04] Np, that's the ibm/lenovo name, I think, hmm [11:04] wikipedia redirects to "Pointing stick" [11:04] nipple [11:04] mpt: that looks great :-) [11:04] i think there's an xcd for this [11:04] xkcd [11:05] "pointing stick" is a pretty poor name. which kind of stick doesn't point? ;) [11:05] it doesn't even look like a stick [11:08] mpt: the left pane has a (vertical) scrollbar, doesn't it? [11:08] tseliot, I'm not sure yet whether it will need one [11:08] the name "TrackPoint" should be enough for me to filter it out (As it can't be unplugged) [11:09] 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] mpt, "pressure of last touch" should be "pressure of last tap" under the "minimum pressure to register a tap" [11:10] ogra, whether the touch counts as a tap is precisely what you're configuring :-) [11:11] 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] 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] ogra, yes, the one on the left is for moving the pointer as opposed to clicking [11:12] ogra: ok [11:12] mpt: ah, ok. Are you sure I shouldn't start implementing that? [11:13] The minimum pressure needed to touch for moving is a different setting from the minimum pressure needed to tap for clicking, aiui [11:13] 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] tseliot, if you can get it done for Karmic, you could implement the one labelled "Version 1" on p3 [11:14] Riddell, afaik there are some tools that expect it to be linux-headers-2* [11:14] tseliot, because it's a clean subset of the rest of the interface [11:15] (well, nearly clean) [11:16] mpt: ok, does the Secondary click include corner tapping (top left, etc.) or did you remove those lines in the draft? [11:18] 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:18] Launchpad bug 386017 in hundredpapercuts "Brushing right-edge of trackpad causes clipboard to paste text" [Undecided,Confirmed] https://launchpad.net/bugs/386017 [11:20] mpt: let's experiment a bit then [11:20] 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] mpt: would it be possible to add middle click below secondary click? [11:22] (disabled by default) [11:22] probably [11:22] ok, good [11:23] 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] and similarly if the touchpad has more than two buttons, the middle-click setting needn't appear [11:24] how would the left-handed vs. right-handed setting work? === MacSlow is now known as MacSlow|lunch === beuno_ is now known as beuno [11:26] mpt: also, couldn't we let users decide whether to use buttons on corner tapping for right clicks or middle clicks? [11:28] 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] but I see now there's no such option in the man page [11:29] 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] ah, ok. I'm right handed ;) [11:30] tseliot, I don't understand the difference between that question and what we were talking about 15 minutes earlier [11:30] so, we could add the corner options to the menus for both secondary and middle click [11:30] the only tricky design detail of that is how to prevent conflicts [11:31] 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] mpt: If I understood correctly, you said that we should hide those settings when the buttons are available [11:40] 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] 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] 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] 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] 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] tseliot: ok, I've finally found that function === MacSlow|lunch is now known as MacSlow [12:35] tseliot, correct [12:36] tseliot, on the assumption that using a dedicated secondary-click button is more convenient than tapping in a corner [12:46] mpt: If I understood correctly, you said that we should hide those settings when the buttons are available [12:46] I find it far easier to cornertap than to left+right simultaneously click [12:47] maxb, right, so that setting would be present if the touchpad has <3 buttons [12:48] I don't think you should completely hide settings ever. Default them sensibly yes, but don't hide them [12:49] For instance, I'll cornertap to right click sometimes, because the physical buttons on the early AAOs suck [12:49] Besides, someone may habituate to using one set of settings across all of their devices [12:49] cornertap never seems to work for me =\ [12:49] I've learnt how to do it properly now [12:50] 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] ok, fine, if the setting is completely useless, yes [12:51] But don't hide settings on the _assumption_ the user won't want them (e.g. cornertapping) === slacker_1l is now known as slacker_nl [13:18] if there is a wrong node created fro dvd drive, which package is problematic? udev or devicekit-disks? [13:20] i officially no longer understand who's in charge of what in device nodey land [13:20] directhex, the who is easy :) its either pitti or Keybuk :P [13:21] ogra: perhaps he meant which package. :-) [13:21] indeed he did :) [13:21] i guess its udev though [13:22] devkit should only operate on top of the nodes [13:23] Ok. I just hope my bug gets solved soon. :-) [13:24] what nodes do you see for your dvd ? [13:24] my laptop has dvd1 and dvdrw1 [13:24] seems about right [13:25] 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] slytherin: what's the bug? [13:26] likely that the kernel doesnt set a dvd capability right [13:27] Keybuk: bug #414665 [13:27] Launchpad bug 414665 in udev "[karmic] /dev/cdrom3 node created instead of /dev/dvd" [Undecided,New] https://launchpad.net/bugs/414665 [13:27] slytherin: attach output of "udevadm info -q all -n sr0" [13:27] mpt, maxb: I always use corner tapping even though my touchpad has physical buttons [13:27] Keybuk: I am not at home right now. Will do that when I go home. [13:28] tseliot, why? [13:28] slytherin: you have no /dev/dvd* symlinks at all? [13:28] hyperair: maybe because of this bug? http://bugs.freedesktop.org/show_bug.cgi?id=23102 [13:28] Keybuk: None. It was surprising for me too. [13:28] Freedesktop bug 23102 in Input/synaptics "Touchpad vertical edge scrolling area not flush to the right" [Normal,New] [13:28] slytherin: probably not a udev bug then; your drive is likely not identifying itself properly [13:29] mpt: I find it quicker to tap as opposed to use another finger (or to move the same finger) to click [13:29] Keybuk: I bought it (second hand) from a friend. Let me talk with the original owner. [13:29] slytherin: if those symlinks are missing, it's not exactly earth-ending [13:29] hi all [13:30] 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] slytherin: totem does not use them [13:31] libdvdread seems to be using it, it complains about 'no /dev/dvd device'. But let me get with more information. [13:32] I don't think anyone has a /dev/dvd symlink anymore [13:32] it's probably /dev/dvd481 by now [13:32] * ogra has dvd1 [13:32] lrwxrwxrwx 1 root root 3 2009-08-17 11:07 /dev/dvd -> sr0 [13:32] tseliot, but if you're moving to the corner you have to move your finger anyway, right? [13:34] Laney: the "I only installed yesterday" crowd are exempt ;) [13:35] 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] tseliot, ok [13:35] Keybuk: I installed several years ago! [13:36] 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] unless you've been manually fixing it [13:36] no, not at all [13:36] aren't you lucky then ;) [13:36] tseliot: no, my circular scrolling corner works [13:37] well, the drive itself is shagged [13:37] so it's pretty useless to have it :( [13:37] there should be a symlink for that! [13:37] /dev/kaput -> sr0 [13:38] hyperair: what happens then? Can you file a bug report about it, please? [13:39] tseliot: wait, i just tried and it works intermittently. [13:39] tseliot: but i can't trigger it consistently [13:39] 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] Launchpad bug 414986 in open-iscsi "open-iscsi causes FTBFS for anything that Build-Depends on it" [High,Triaged] https://launchpad.net/bugs/414986 [13:39] jdstrand: yeah, bummer, i saw that [13:40] hyperair: ok, it's still worth filing a bug about it though ;) [13:40] 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] tseliot: no wait, it seems like i can trigger it consistently now, but there's a lag of ~0.5-0.7s [13:40] tseliot: basically i have to tap, and then wait for a response [13:40] 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] hyperair: does this happen irrespectively of the window you're tapping on? e.g. firefox, the desktop, etc. [13:41] tseliot: yes [13:41] kirkland: that could work too-- it would need to provide iscsiadm in the case of libvirt [13:42] hyperair: it's a bug then [13:42] tseliot: hmm not misconfiguration? [13:42] tseliot: is there any synclient setting i could try tweaking? [13:42] kirkland: so -dev might not be the best name for it [13:42] kirkland: maybe -tools? [13:42] jdstrand: sure, fair enough [13:43] kirkland: and open-iscsi pulls in open-iscsi-tools? [13:43] jdstrand: the key is for it *not* to have an init script [13:43] jdstrand: right [13:43] tseliot: ah, it seems that turning on FastTaps improves it [13:44] hyperair: but doesn't that alter normal (i.e. non-corner) tapping? [13:44] kirkland: is that something you plan to do? [13:44] jdstrand: i can do it if you need me to; i had other plans for my day, though :-) [13:45] jdstrand: what else needs to be in there besides iscsiadm ? [13:45] I did too... all I want is libvirt to build, I didn't ask to get in the open-iscsi quagmire... [13:45] :) [13:45] jdstrand: :-D [13:45] hyperair: I meant double tapping [13:46] jdstrand: okay, give me what needs to be moved from open-iscsi to open-iscsi-tools [13:46] jdstrand: i'll build/test/upload, you can review and accept [13:46] 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] kirkland: well, for the time being I worked around it for my libvirt package by building with --without-storage-iscsi [13:47] kirkland: I think this is ok for my ppa [13:47] jdstrand: right; i had to do the same for my hardy backport of libvirt, similar reasons [13:48] kirkland: it appears libvirt will build on an official buildd [13:48] jdstrand, kirkland: maybe open-iscsi should simply not fail in the mainter script if the invoke-rc.d fails? [13:48] tseliot: yes it does. basically it reacts slower than a button tap, and so it confuses me =\ [13:49] tseliot: and sometimes, presumably because i didn't tap near enough to the corner, it doesn't respond. [13:49] 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] huhu sebner [13:49] tseliot: basically i find it very unreliable and not a replacement for the clicking of touchpad buttons [13:49] sistpoty|work: I thought of that too, but wasn't comfortable making the change [13:49] kirkland: what do you think? ^ (of both) [13:50] hyperair: I agree but it depends on the touchpad model [13:50] (a cleaner approach is always preferrable though than my suggestion ;) [13:50] tseliot: perhaps. my touchpad's an alps model [13:50] jdstrand: fedora has iscsi-initiator-utils [13:50] tseliot: all the fancy multi-finger options fail. [13:51] hyperair: I don't own alps touchpads but similar problems can take place with synaptics too [13:51] hyperair: that depends on the fact that the touchpad doesn't support multi-touch and emulates it [13:51] (badly) [13:51] 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] 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] hyperair: it's a matter of taste too [13:53] 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] tseliot: mine are nice and quiet, and also if you press the centre, you will nicely trigger both buttons. [13:53] kirkland: so you can do it today, we can wait or I can change the initscript to not return error. opinion? [13:54] jdstrand: i'm hacking on it now [13:54] could any developer here sponsor/give me some hints on how to work on https://bugs.launchpad.net/ubuntu/+bug/413989 ? [13:54] Ubuntu bug 413989 in ubuntu "karmic: huawei gsm modem not working anymore" [Undecided,New] [13:54] 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] jdstrand: if i give you an iscsi source package, can you test it in your pbuilder? [13:54] jdstrand: :-) no worries, i walked right into this one.... [13:54] kirkland: oh yes, I can test [13:55] jdstrand: what's the bug # for the changelog? === kenvandif is now known as kenvandine [14:01] 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] jdstrand: okay [14:01] kirkland: 414986 [14:01] jdstrand: thanks [14:01] jdstrand: i'm tweaking it now [14:02] 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] jdstrand: hmm, okay, i having trouble with something simple here [14:06] jdstrand: i have /sbin/iscsiadm in a new open-iscsi-utils package [14:07] jdstrand: how do i exclude it from the open-iscsi package? [14:07] * jdstrand looks at the packaging [14:08] kirkland: so in debian/rules, we have: [14:08] install -m 755 usr/iscsiadm $(CURDIR)/debian/open-iscsi/sbin [14:09] kirkland: that should simply be changed to: [14:09] jdstrand: duh! [14:09] install -m 755 usr/iscsiadm $(CURDIR)/debian/open-iscsi-tools/sbin [14:09] jdstrand: okay, sorry [14:09] jdstrand: sorry, i created an open-iscsi-utils.install file [14:10] ah, yes. well should work too, but you'd have to adjust debian/rules regardless [14:10] jdstrand: and was looking for the same, [14:10] jdstrand: okay, i'm moving it, and the manpage [14:13] jdstrand: http://pastebin.ubuntu.com/255112/ [14:13] jdstrand: give that a go [14:14] jdstrand: http://pastebin.ubuntu.com/255113/ [14:15] 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] jdstrand: i don't know ... i was able to install it alone, and run it, and get the usage statement [14:17] kirkland: ok. I'll take a look at it here [14:17] 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] it looks like it should work just fine, I just wanted to make sure that iscsiadm would work ok on its own [14:25] jdstrand: well, that's sort of why i proposed calling this a -dev package, as those rarely provide standalone execute functionality === robbiew_ is now known as robbiew === dholbach_ is now known as dholbach [14:37] jcastro: Do you know if the videotaped UDS sessions are going to make it online? (non-plenary) [14:38] I'm looking for an example of someone maintaining packaging in a bzr branch. [14:38] Something that's properly split into an "upstream" and an "ubuntu" branch [14:40] superm1: what's the status of DKMS flushing stdout? [14:42] 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] superm1: ok [14:46] kirkland: configure: iSCSI: yes [14:47] 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] jdstrand: yeah, i grepped through there [14:47] if it does need something, it is easy enough to change later [14:47] jdstrand: ack [14:47] jdstrand: did your libvirt build? [14:48] kirkland: that was the 'configure: iSCSI: yes' I mentioned [14:49] jdstrand: ah, okay [14:49] jdstrand: i'm uploading then [14:49] jdstrand: cool? [14:49] kirkland: yeah, go for it [14:49] kirkland: thanks :) [14:50] jdstrand: done ;-) you're welcome :-) === magnetic_ is now known as foolano [15:03] 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] (i.e., assume utf-8 is the local charset, other charsets be damned?) [15:23] 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 === pochu_ is now known as pochu [15:42] 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] but I'm going to stick to utf-8 until someone complains [15:42] liw: what program would that be for? [15:43] does it matte? [15:43] 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] Laney: yeah, you're the second person to trip over that [15:44] https://wiki.ubuntu.com/DistributedDevelopment/Documentation/WorkingOnAPackage [15:44] oh [15:44] I need to branch? [15:44] perhaps I should switch it round so that GettingTheSource gets you a full branch [15:44] yeah [15:45] I thought that was optional, like for a topic-branch [15:45] the intent is that you always have a pristine copy of trunk, and then use feature branches [15:45] alright [15:45] yeah, it is optional, but it is good practice [15:45] the pristine copy is important for merging, but perhaps I should move it to be a step in the merging process [15:46] james_w: how about just a note in the GettingTheSource package that you should branch to work on an update? [15:46]