[00:00] bigon: ping === herb__ is now known as herb [02:21] Aha! Pulse's hal module works backwards through card numbers/indexes, and since the pc speaker card is the last in the list, its chosen first. :S [02:30] TheMuso: that seems... backwards? :) [02:31] slangasek: Agreed. I'm now reading the hal-detect module code to see if can be somehow blacklisted/patched around. === tritium_ is now known as tritium [04:27] anybody here use xchat-gnome and notice that it pegs the CPU when you open up the preferences? [04:28] slangasek: is it OK if a upload a gnumeric package with Recommends: evince | evince-gtk? Or is it better to move evince to Suggests? [04:28] LaserJock: I can reproduce that, but hadn't previously noticed. That said, isn't that a bug? [04:28] LaserJock: Yes. I'm pretty sure it didn't do that in Hardy. [04:28] johanbr: this is Hardy [04:28] johanbr: It does it in hardy. [04:29] Oh, it does? I must be wrong then. :) [04:29] In that case, the bug is still there in Intrepid. :) [04:29] gpocentek: Just out of curiosity, is the core issue not resolved by the split between gnumeric & gnumeric-gtk? Is there perhaps something else involved? [04:29] huh, it's odd that it would make it this long [04:30] Lots of people wouldn't notice, as they'd edit the preferences while not doing other things. [04:31] persia: the split has been dropped, and the problem is that we have both evince and evince-gtk being installed [04:31] hmm, I guess I wouldn't have noticed it as readily if I didn't have a CPU monitor [04:31] which failed obviously [04:31] gpocentek: Ah. Right. I seem to have misread the changelog. [04:31] gpocentek: thanks for dropping the -gtk stuff for goffice, upstream complained about that quite a bit [04:33] Quick question for intrepid. Do people care if the PC Speaker is not available as a sink in PulseAudio? :) [04:34] TheMuso: By default, or at all, ever? [04:34] persia: Currently it is kind of used by default, due to the way hal-detect works through finding devices, but yes, ever as well. [04:35] If you do a fresh install of intrepid today, and your machine has a PC speaker, pulse will use it. [04:35] Not being available by default ought solve the exceedingly common complaint by those with a "single sound card" who don't want to use the asoundconf set-default-card macro. [04:35] persia: bug #192967 has been "Triaged" and sent upstream sinc Feb. [04:35] On the other hand, not being available at all could well be regarded a bug. [04:36] Launchpad bug 192967 in xchat-gnome "Preferences window of xchat-gnome eats 100% of the CPU" [Medium,Triaged] https://launchpad.net/bugs/192967 [04:38] persia: Yeah. At the moment, I have a patch to completely ignore the PC speaker, so that only sound cards are available to pulse, however I am going to see whether its possible to reverse the index traversal in pulseaudio. [04:39] Thereby having the pc speaker still available, but not default. [04:39] LaserJock: From reading, I think that's a well described bug. Just needs someone to fix it :) [04:40] persia: apparently [04:41] TheMuso: As a temporary fix, completely disabling makes sense, as long as that doesn't drop off the list of things to fix by release. Can we maybe do something with asoundconf --set-default-card? That seems to fix the "horrible buzzing noise" for many people. === asac_ is now known as asac [04:42] persia: Nothing to do with pulseaudio. Pulseaudio uses hal to find devices, and it searches the index of soud cards in reverse order, as in, highest to lowest. I think doing lowest to highest is a better bet. [04:42] Note that I've never heard a positive review of the PC Speaker as an output device, but I presume there is some use case for which it makes sense. [04:42] So if I can do that right off, then its all done and not needing to worry about it. [04:42] getting rid of the PC speaker kernel module is usually one of the first things I do [04:43] can't stand that stupid thing [04:43] TheMuso: Interesting. I was sure a couple people reported that the asoundconf macro fixed it for them. Maybe an upgrade vs. install thing. [04:43] persia: Considering pulse uses hw:index to access the device, thats possibly it, but they may have also set their output to use alsa exclusively. [04:45] TheMuso: Right. [04:48] As it is, I think I've found the code that iterates through device indexes. [05:22] where can I find documentation on x.org programming? [05:23] x.org doesn't seem to have any === mcasadevall_ is now known as NCommander [06:26] hi al [06:26] hi all [06:28] for the past one week i am trying to compile bmpanel 0.9.24 from the source and ./configure doesn't show any dependency problem but make doen't compile the application [06:28] what might be the problem? [06:30] i think that it is not a dependency problem . [06:31] perhaps we don't use the latest libraries [06:32] i have been directed to this channel by #ubuntu . [06:32] i am newbie too please help me . i really want this application to be installation in my hardy [06:33] i even installed intrepid to see if it can be compiled but i am not able to do it there either. [06:34] http://paste.ubuntu.com/29858/ [06:34] the pastebin [06:35] home page of bmpanel http://nsf.110mb.com/bmpanel/ [06:37] if this can't be done in this channel can u tell me what is the channel that i can get help from ? [06:38] murlidhar: install libc6-dev, but this is not a support channel. [06:38] or atleast what exactly the problem is ? [06:38] anyone ? [06:38] apart from that, go ask those who make bmpanel. [06:39] Hobbsee: k thanks [06:40] Hobbsee: btw libc6-dev is already the newest version . [06:40] Hobbsee: so do i compile libc6-dev from source and see if it works ? [06:40] murlidhar: then go ask the people who make bmpanel. [06:41] this is *not* a place for support. [06:41] as the /topic says. [06:44] Hobbsee: sorry and thanks i am asking them right now [06:44] Hobbsee: actually i am tryin to install it from the past one week . so i was a bit frustrated . [06:47] gpocentek: gnumeric having a recommends: on evince seems questionable to me; does the relationship really fit the definition of Recommends? [06:48] gpocentek: but yes, it's ok with me either way [06:52] slangasek: my feeling is that it should be turned in a Suggests, evince is only needed to read the exported pdf files AFAIK [06:53] gpocentek: then that agrees with my sense, but the decision is up to you [06:53] gpocentek: especially when a lot of other apps can be used to read the pdfs [06:53] LaserJock: true [06:58] * TheMuso has come up with a patch to ensure the PC speaker is not the default sink/output for pulse, but the PC speaker option is still avaiable for those weird ones who still want it. [07:30] slangasek: is this pulse fix something we might want for the alpha? Or are we too far gone to include it? === tkamppeter_ is now known as tkamppeter [09:17] slangasek: ask you about what? [09:17] slangasek: usplash? well, I can't really tell; it's hopelessly broken for me either way, I'm afraid :/ [09:21] Good morning [09:25] Morning pitti [09:31] morning [09:31] * Hobbsee waves [09:33] hello everybody [09:43] seb128, ping [09:43] hey NCommander [09:43] seb128, I've got gucharmap packaged [09:43] Expect for the python bindings [09:43] waouh ;-) [09:43] oh? [09:43] Which I don't think will be possible unless we kick CDBS [09:44] It builds the bindings through ./configure [09:44] why ? [09:44] It doesn't use the nice easy python build system [09:44] So configure will have to be run multiple times in a proper environment to build bindings for each version [09:44] (and even then, I'm not sure how to get it to work, configure doesn't even catch that libpython on Debian is libpython-*ver* [09:44] ah, that, yes, that's unpleasant :-( [09:45] yeah [09:45] So you can have the package now, or you can wait for me to make it into a makefile based rules which does some unholy thing to build the bindings [09:46] It will essentially require rebuilding configure twice with a different python version coded in (since its hard coded to libpython, and I don't want to even try and get it to build the bindings twice in the same path) [09:46] did the soname changed? [09:46] s/path/pass/s [09:46] seb128, yeah, I got that, its 7 [09:46] I changed the depend on the dev file so it will install the new library automatically if the -dev package is installed [09:47] ok, so I'm not going to upload that today due to the intrepid alpha 3 freeze [09:47] seb128, yeah, I got that email :-P [09:47] avoiding soname changes now, that can be disruptive [09:47] seb128, so you want it without the bindings? [09:47] you can look to gnome-menus for an example [09:47] (I personally thing it will be very ugly to fix) [09:47] I did migrate the lp patch which was fun [09:47] A few variable names changed -_-; [09:47] it builds python binding and uses cdbs [09:48] seb128, no, building the bindings with CDBS on a normal python package that uses setup is easy [09:48] I've never seen a package that uses configure to build python bindings [09:48] all the GNOME packages tend to use configure only [09:49] *fun* [09:49] Ugh, this is an ugly rules file, even for CDBS [09:49] yes ;-) [09:50] cdbs doesn't make multi-builds friendly [09:50] ew [09:50] Yeah [09:50] I was ... [09:50] Ew [09:50] * NCommander twichs [09:50] THere is a reason I despise CDBS [09:50] I'm staring at it right now [09:50] ;-) [09:50] cdbs is great for packaging easily easy things [09:50] ie, most of GNOME where you only need to ./configure && make && make install [09:51] Yeah, and blows up in your face when the package maintainer does something slightly different [09:51] * NCommander uses the time honoured tradition of copy and paste coding [09:54] * mvo devel machine just turned itself off spontaneously - that is slightly disturbing [09:56] mvo: did it let out any magic smoke? [09:56] hello, if I wanted to hack glxinfo (from the mesa-utils package), how should I retrieve the source ? [09:58] apt-get source mesa [09:58] Also, probably off-topic :) [09:59] RAOF: thanks :) [10:00] Of course, if you wanted to contribute upstream you'd be after cgit.freedesktop.org/mesa/mesa [10:00] Should compiz kick in on intel gfx cards by default in intrepid? [10:00] mvo: power-spike maybe? [10:01] The membership of Daniel Holbach (dholbach) in the MOTU (motu) team has [10:01] expired. [10:01] [10:01] ... [10:01] * Keybuk wonders whether that was supposed to happen [10:01] mvo: I had that once several years ago. went out for a bit, and when I came back, my pentium machine had rebooted, and my 486 was still running [10:01] 486 had a better power-supply apparently :) [10:02] Keybuk: yes, it's deprecated. [10:02] Hobbsee: no, it's not [10:02] we haven't deprecated the MOTU :p [10:02] oh, we've deprecated ~ubuntu-dev. i think. [10:02] oops [10:02] it might be fun to deprecate the MOTU, though :P [10:03] I suspect he just missed the expiry mails due to being on his road-trip [10:03] * Keybuk extends it another month so he gets a chance [10:03] that'll teach him to go on holiday :) [10:03] bug #197762 [10:03] yeah, it annoys me that they only get a week [10:03] Launchpad bug 197762 in gvfs "file transfer on USB disk slows down with gvfs" [Low,Triaged] https://launchpad.net/bugs/197762 [10:04] on recent comment suggests that using pci=routeirq workaround the issue, on amd duo core system using nvidia chipsets [10:04] is that a known issue? linux bug? [10:09] RAOF: no, I'm just trying to alter the glxinfo output... [10:09] for testing purpose [10:09] RAOF: regarding this issue if you mind: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/250792 [10:09] Launchpad bug 250792 in linux-restricted-modules "Adobe Flash hardware acceleration support (GPU)" [Undecided,New] [10:10] Chipzz: heh :) happend last night too, I suspect something HW releated, I will have to keep a eye on it [10:11] seb128, this is pure evil in its most unadultrated form; is there any reason why the desktop seem is in love with CDBS? [10:12] NCommander: because rules are clean and short most of the time [10:13] seb128, Normally, but for packages like this, it just seems like a headache (I'm not trying to bitch (much), although this is probably going to make me go a little nuts once I finish) [10:13] mdz: do you still have a current checkout of lp:~ubuntu-core-dev/casper/trunk ? bzr getting that fails, maybe you can "bzr check"/"bzr reconcile" on your end and push again? [10:13] mdz: asking you because it says something about "KnitCorrupt: Knit text:x_Matt_Zimmerman_" (although that is already very old) [10:13] NCommander: while I'm not always in love with the implementation I think the idea behind it is really good, currently there is just too much cargo-culting and copy/n/paste going on where we really want to have a simple "build-me-a-standard-gnome" package rule [10:14] pitti: there's a bzr bug open about that [10:14] AlexCONRAD: Ah, right. I suspect you're on a hiding to nothing trying to munge glxinfo until closed-source flash deigns to use GL acceleration. [10:14] mdz: ah, will have a look [10:14] mvo, maybe its time for a debhelper gnome rule ;-) [10:14] pitti: https://answers.launchpad.net/launchpad-bazaar/+question/39693 [10:14] debehlper7++ :) [10:14] pitti: I do have a local tree [10:15] NCommander: agreed that multi-builds are ugly when using cdbs [10:15] RAOF: I'm just trying to compile to have a dummy hardcoded string in there [10:15] mdz: I don't suppose you happen to have a copy of the old matt.zimmerman@canonical.com--2004/casper--main--0 arch repository? that's the missing bit [10:15] pitti: check/reconcile doesn't help, BTW [10:15] cjwatson: http://people.ubuntu.com/~mdz/bazaar/casper/ [10:15] NCommander: well, not more or less ugly than with plain debhelper, it's just that cdbs won't help you with multibuild [10:16] are ddebs for hardy-backports available somewhere? [10:16] pitti: bug 246880 [10:16] Launchpad bug 246880 in bzr "Can't branch casper which misses some parents in old revisions" [Undecided,New] https://launchpad.net/bugs/246880 [10:16] SniperBeamer: I currently don't grab/archive them [10:16] seb128, it might be less evil to simply manually build the python bindings with the appropriate GCC commands then force a multibuild :-P [10:16] pitti: lifeless said he would try to help with it during the sprint, not sure who he worked with [10:16] ddebs.ubuntu.com doesn't have them [10:16] he worked with me [10:16] we only succeeded in making it worse [10:17] pitti: Could I beg you to source NEW wpeditor? [10:17] pitti: And you *might* be able to NBS out libgpmg1. [10:18] mdz: no, those appear to be matt.zimmerman@canonical.com/casper--main--0, not matt.zimmerman@canonical.com--2004/casper--main--0 [10:18] cjwatson: sorry, i meant http://people.ubuntu.com/~mdz/bazaar/matt.zimmerman@canonical.com--2004/ [10:18] cjwatson: or http://people.ubuntu.com/~mdz/bazaar/matt.zimmerman@canonical.com/ [10:18] aha [10:18] thanks, might be able to piece the ghosts back together from that [10:18] Hm. hppa might actually be catching up. [10:19] StevenK, hppa's toolchain is not happy though [10:19] mind you, that means I have to install baz ... [10:19] hooray for never deleting anything [10:20] seb128, I think its a bad sign when ./configure getting run in the autotools-files stamp -_-; [10:22] NCommander: It isn't? [10:23] this is a relief, I have completely forgotten how to drive baz [10:24] Anyone can tell me what's wrong with this lintian override? [10:24] codeblocks binary: script-not-executable usr/share/codeblocks/lexers/lexer_bash.sample [10:24] (I get this from lintian: W: codeblocks: script-not-executable ./usr/share/codeblocks/lexers/lexer_bash.sample) [10:25] NCommander: it apparently has a hashbang line, but is 0644 [10:25] pitti, no, this needs to be overrided, the .sampe is a data file [10:25] It has a hasbang, and its needed [10:25] It's not susposed to be an executable script [10:26] I'm just trying to figure out why my override file isn't working [10:27] NCommander: if it has a hashbang, why shuoldn't it be executable? [10:28] pitti, It's used by the bash lexer as an example script to show when you change settings; its never executed by codeblocks, its simply used as a test by the lexer, and shown in the IDE to show how changes to a lexers settings will effect rendering [10:29] NCommander: try using "./usr/share/codeblocks/lexers/lexer_bash.sample" in the .lintian? [10:29] seb128, I had tried it :-/ [10:29] THe only thing that has worked thus far is simply killing the entire wanring [10:29] NCommander: and why do you add "binary"? [10:30] "codeblocks: script-not-executable ./usr/share/codeblocks/lexers/lexer_bash.sample" [10:30] try that? [10:30] loose the binary line? [10:30] seb128, cause thats what the documentation says [10:33] seb128's suggestion is correct [10:33] I tried putting it in /usr/share/lintian/overrides/codeblocks to test, I still get the warning [10:33] I'm not sure about the binary bit, the lintian documentation does say it's optional [10:34] but copying and pasting the output without the initial W: or whatever should work [10:34] NCommander: it needs to be in the package itself [10:34] Note that Lintian extracts the override file from the (u)deb and stores it in [10:34] the laboratory. The files currently installed on the system are not used in [10:34] current Lintian versions. [10:34] ^- from the lintian manual [10:34] cjwatson, I was rebuilding the package, ccache makes it loads faster [10:34] It's just finishing the install rules [10:49] seb128, I think I'm going to need help on this, I honestly am fairly stumped on how to make this do a multipass build; I don't use CDBS at all in my packages [10:50] NCommander: did you try to copy what gnome-menus does? [10:50] seb128, yeah, I can't even make it run the right configure target [10:50] configure/gucharmap:: $(addprefix configure-stamp-, $(PY_VERSIONS)) - doesn't work (nor does just configure::) [10:51] do you have ".PRECIOUS: configure-stamp-% dbg-configure-stamp-%"? [10:52] seb128, .PRECIOUS: configure-stamp-% dbg-configure-stamp-% [10:52] Yup [10:52] can you copy your .diff.gz somewhere? [10:53] seb128, I can stick it on revu [10:53] just copy the rules on http://paste.ubuntu.com maybe, that will be faster [10:54] seb128, ok [10:54] seb128, http://paste.ubuntu.com/29906/http://paste.ubuntu.com/29906/ [10:54] er http://paste.ubuntu.com/29906/ [10:56] NCommander: does changing configure/libgucharmap7 to configure/gucharmap makes any difference there? [10:57] seb128, nope [10:57] I went through every variation that made sense there [10:58] and what error do you get? [10:58] seb128, no error [10:58] seb128, it runs the default CDBS build rule [10:59] * NCommander is not a CDBS guru, and has never encountered a Makefile debugger :-P [11:00] hum [11:02] seb128, maybe its easier to simply upload the gucharmap package into the delayed queue without python, and then file a wishlist bug :-P [11:02] ALthough I'll probably take three or more stabs at it before I give up in frustation and rewrite the rules file [11:02] and then watch that diff.gz get rejected :-P [11:03] NCommander: you did use "DEB_BUILDDIR := build" but that should make a real difference [11:04] touch debian/stamp-autotools-files [11:04] chmod a+x /build/gucharmap/gucharmap-2.23.4/./configure [11:04] It's not :-P [11:04] Let me post the build log [11:05] in fact I don't think you need the .PRECIOUS line [11:05] seb128, I've tried without it [11:06] seb128, you can scratch your head just like I am [11:06] I hate cdbs multi builds ;-) [11:06] Just say the word and I'll redo the build file in a sane way ;-) [11:07] the word [11:07] jcristau, I need it from my mentor (and the guy who's going to be uploading it :-P) [11:07] NCommander: oh, you have 2 clean targets in this rules [11:07] that's not good ;-) [11:07] I swear, if that was it [11:07] I'm going to scream [11:08] and file a bug against CDBS: "Too ugly to live" [11:08] *phew* [11:08] No change in output, still not calling configure with the proper environmental PYTHON variable [11:11] NCommander: ok, please put the diff.gz somewhere ;-) [11:11] NCommander: damn. :) [11:11] * NCommander kicks it onto REVU [11:12] but maybe we should use debhelper for packages which need multi builds [11:12] I would like to figure what is wrong there though [11:12] seb128, I'd like to know what was wrong as well, but there is a point where the pain just becomes too much [11:13] seb128, it looks like it should work, right? [11:13] NCommander: yes [11:13] Or at least, try to build in build [11:15] seb128, its on its way to revu [11:15] ok [11:18] seb128, http://revu.tauware.de/details.py?package=gucharmap [11:18] seb128, ignore the lintian warnings, I hadn't cleared them when I tried to make it do multbuilds [11:20] looking [11:25] any archive admin that can process bug 248060? [11:25] Launchpad bug 248060 in ubuntu "Please sync lwt 1.1.0-2 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/248060 [11:26] seb128, As an aside, codeblocks just made it into the archive, wooo [11:27] seb128, any chance I can ask you to sponsor it into Debian at some point (and a fix for my other debian package) [11:27] NCommander: I can do that yes [11:27] seb128, that would be awesome if it isn't much trouble [11:28] seb128, (I'd ask ask for sponsoring for D-Maintainer once I prove to you I can package ;-)) [11:29] ;-) [11:29] wow, I think Launchpad's karma counter has a bug [11:29] NCommander: gucharmap seems to work correctly [11:29] I just jumped from 2000 to 6671 [11:29] seb128, what, the one I uploaded? It doesn't even build here [11:29] (unless you undid my rules changes) [11:29] NCommander: at least it calls configure using the correct PYTHON=`which python2.5` etc [11:30] .... [11:30] It likes you and not me [11:30] well, it seems to be calling the configure a first one without argument [11:30] then cd build-python-2.5 [11:30] and then call it correctly [11:30] seb128, that's failing for me [11:30] s/first one/first time [11:30] I thought I needed the PYTHON=* to make that work [11:31] (and as an aside, what dependency do I need installed then, and added to the control file) [11:31] I moved the --enable-python-bindings to the configure-stamps arguements [11:31] forgot to mention that [11:31] Ah [11:31] Yeah [11:31] which means the first configure call doesn't try to do that [11:32] now it fails on gucharmap/gucharmap.h.in not being available [11:32] seb128, that's pretty ugly, but it does work [11:32] seb128, well, now that its actually trying to build, I can probably resolve it [11:32] I guess it doesn't like building out of the sc dir [11:32] src dir [11:32] It probably means a giant search/replace is going to hit every Makefile.am file [11:33] Cause I don't think there is any way to build this inside the build directory [11:33] why? [11:34] seb128, yeah, take a look at the Makefile.am's they're using relative paths, and not the full syntax (the $(source)\gucharmap\file.c you need to get out of source builds) [11:35] Unless there is an arguement you can pass to autoconf, the only way I know how to fix it is to manually fix each and every line [11:36] seb128, any suggestions before I got editing happy on the Makefile.am's? [11:36] seb128: once you have finished your love affair with NCommander (:-)) could you please push bug 248060? Its needed to have ocsigen build correctly (and was requested 2 days before ocsigen to avoid it ftbfs) [11:36] Launchpad bug 248060 in ubuntu "Please sync lwt 1.1.0-2 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/248060 [11:36] NCommander: what is the error exactly? [11:37] ooh [11:37] I just got an absolutely sick way to fix this [11:37] norsetto: not a love afair and I read your comment before and it's in the ubuntu-archive bugs list, there is no need for extra pinging [11:37] But it wouldn't require patching every makefile [11:37] seb128: after 10 days, yes, there is .... [11:37] norsetto: sorry I was travelling for GUADEC and distro sprint and seems other archive admins have been busy too [11:37] norsetto: why is it urgent? [11:38] seb128: because if causes ocsigen to ftbfs [11:38] well, that would be nice to fix but it doesn't seem particularly urgent [11:38] I'll do the sync now anyway [11:39] * norsetto hugs seb128 [11:39] seb128, I think cp -r * build-$* might be excessively too ugly to live [11:40] NCommander: I tried to "mkdir build; cd build; ../configure" and that seems to work, weird [11:40] My solution was to simply copy the source directory into the build directory ;-) [11:41] seb128, CDBS is probably doing something rather nasty to the envornment thats causing it not to work [11:41] feel free to rewrite the rules using debhelper if you think that would make things easier and cleaner [11:42] seb128, O_o; what made you give up CDBS and let me rewrite the rules :-P [11:43] Well, if this just works by cp -r'ing the build directory, its probably easier to stay with CDBS if we ever want these changes to go upstream [11:43] I don't care that much about using cdbs for multibuild, that's often ugly [11:43] maybe there is some srcdir that need to be changed to builddir in a makefile [11:44] seb128, well, at this point, I actually got it building as a multibuild [11:44] oh? [11:44] Well, mostly, I'm tweaking it as it fails, but it appears to now be somewhat working [11:45] seb128, http://paste.ubuntu.com/29925/ - take a look at what I did [11:45] bah [11:45] that's ugly [11:46] You've got to give me points for thinking outside the box ;-) [11:46] what breaks it is the srcdir=. given to the configure [11:47] so just force srcdir=..? [11:48] that would work I guess, but I'm trying to figure why srcdir=. is used [11:48] mvo: hello, do you mind being subscribed to bug 105219? [11:48] Launchpad bug 105219 in command-not-found "Pressing control C while command-not-found is runnig is confusing" [Undecided,Confirmed] https://launchpad.net/bugs/105219 [11:49] I believe that bug is now fixed, I added a comment at the bottom of the page [11:49] NCommander: ah, that's because you forgot the "DEB_BUILDDIR := build" [11:50] NCommander: adding that to the rules make it work correctly [11:52] argh, its now not working for me [11:52] is "there is no sound on intrepid when pulseaudio is running" a known issue? [11:52] I see python go in, and then configure goes boom [11:53] seb128, got any idea why it can't link against libpython? [11:53] zyga: sure, please subscribe me [11:56] NCommander: not really, looking at it [12:06] seb128, any luck? [12:14] NCommander: no, I'm a bit puzzled by this one [12:16] seb128, yeah, the libtool line looks like it should work [12:16] NCommander: it's due to the autoreconf patch [12:17] not sure what in it though [12:17] hrm [12:17] moving the patches directory away make it work [12:17] * NCommander just reruns autoreconf [12:17] btw the patch should be an autoconf one [12:17] no need to run automake etc in this case [12:17] only the configure needs updating [12:18] wow [12:18] I mean, WOW! [12:18] intrepid desktop booting fine for me under intrepid kvm [12:18] including usplash [12:18] ;-) [12:18] something is clearly wrong here... [12:19] NCommander: just running autoconf produces a 20 lines patch and doesn't break the build [12:19] NCommander: running autoreconf is looking for trouble ;-) [12:20] Well [12:20] ... [12:20] soren: hm, current intrepid desktop cd under current intrepid (i386: desktop boots fine, but the mouse speed is about 23429 times faster than it should be; known? [12:20] * NCommander shoots himself [12:20] NCommander: btw you want to change the gmenu mention in the rules too [12:20] the egrep command [12:20] seb128, yeah, that already got killed [12:20] soren: at some point we had a scaling problem with the vmmouse driver; did that creep back in somehow? [12:20] soren: (I guess it uses vmmouse?) [12:22] NCommander: seems to build fine now [12:22] seb128, What a headache [12:22] Between autoconf and CDBS ... I apperiate you taking so much time in helping to resolve this [12:22] np ;-) [12:22]