[00:00] <Gunirus> bigon: ping
[02:21] <TheMuso> 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] <slangasek> TheMuso: that seems... backwards? :)
[02:31] <TheMuso> slangasek: Agreed. I'm now reading the hal-detect module code to see if can be somehow blacklisted/patched around.
[04:27] <LaserJock> anybody here use xchat-gnome and notice that it pegs the CPU when you open up the preferences?
[04:28] <gpocentek> 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] <persia> LaserJock: I can reproduce that, but hadn't previously noticed.  That said, isn't that a bug?
[04:28] <johanbr> LaserJock: Yes. I'm pretty sure it didn't do that in Hardy.
[04:28] <LaserJock> johanbr: this is Hardy
[04:28] <persia> johanbr: It does it in hardy.
[04:29] <johanbr> Oh, it does? I must be wrong then. :)
[04:29] <johanbr> In that case, the bug is still there in Intrepid. :)
[04:29] <persia> 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] <LaserJock> huh, it's odd that it would make it this long
[04:30] <persia> Lots of people wouldn't notice, as they'd edit the preferences while not doing other things.
[04:31] <gpocentek> persia: the split has been dropped, and the problem is that we have both evince and evince-gtk being installed
[04:31] <LaserJock> hmm, I guess I wouldn't have noticed it as readily if I didn't have a CPU monitor
[04:31] <gpocentek> which failed obviously
[04:31] <persia> gpocentek: Ah.  Right.  I seem to have misread the changelog.
[04:31] <LaserJock> gpocentek: thanks for dropping the -gtk stuff for goffice, upstream complained about that quite a bit
[04:33] <TheMuso> Quick question for intrepid. Do people care if the PC Speaker is not available as a sink in PulseAudio? :)
[04:34] <persia> TheMuso: By default, or at all, ever?
[04:34] <TheMuso> 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] <TheMuso> If you do a fresh install of intrepid today, and your machine has a PC speaker, pulse will use it.
[04:35] <persia> 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] <LaserJock> persia: bug #192967 has been "Triaged" and sent upstream sinc Feb.
[04:35] <persia> On the other hand, not being available at all could well be regarded a bug.
[04:38] <TheMuso> 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] <TheMuso> Thereby having the pc speaker still available, but not default.
[04:39] <persia> LaserJock: From reading, I think that's a well described bug.  Just needs someone to fix it :)
[04:40] <LaserJock> persia: apparently
[04:41] <persia> 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.
[04:42] <TheMuso> 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] <persia> 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] <TheMuso> So if I can do that right off, then its all done and not needing to worry about it.
[04:42] <LaserJock> getting rid of the PC speaker kernel module is usually one of the first things I do
[04:43] <LaserJock> can't stand that stupid thing
[04:43] <persia> 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] <TheMuso> 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] <persia> TheMuso: Right.
[04:48] <TheMuso> As it is, I think I've found the code that iterates through device indexes.
[05:22] <pushax> where can I find documentation on x.org programming?
[05:23] <pushax> x.org doesn't seem to have any
[06:26] <murlidhar> hi al
[06:26] <murlidhar> hi all
[06:28] <murlidhar> 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] <murlidhar> what might be the problem?
[06:30] <murlidhar> i think that it is not a dependency problem .
[06:31] <murlidhar> perhaps we don't use the latest libraries
[06:32] <murlidhar> i have been directed to this channel by #ubuntu .
[06:32] <murlidhar> i am newbie too please help me . i really want this application to be installation in my hardy
[06:33] <murlidhar> i even installed intrepid to see if it can be compiled but i am not able to do it there either.
[06:34] <murlidhar> http://paste.ubuntu.com/29858/
[06:34] <murlidhar> the pastebin
[06:35] <murlidhar> home page of bmpanel http://nsf.110mb.com/bmpanel/
[06:37] <murlidhar> 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] <Hobbsee> murlidhar: install libc6-dev, but this is not a support channel.
[06:38] <murlidhar> or atleast what exactly the problem is ?
[06:38] <murlidhar> anyone ?
[06:38] <Hobbsee> apart from that, go ask those who make bmpanel.
[06:39] <murlidhar> Hobbsee: k thanks
[06:40] <murlidhar> Hobbsee: btw libc6-dev is already the newest version .
[06:40] <murlidhar> Hobbsee: so do i compile libc6-dev from source and see if it works ?
[06:40] <Hobbsee> murlidhar: then go ask the people who make bmpanel.
[06:41] <Hobbsee> this is *not* a place for support.
[06:41] <Hobbsee> as the /topic says.
[06:44] <murlidhar> Hobbsee: sorry and thanks i am asking them right now
[06:44] <murlidhar> Hobbsee: actually i am tryin to install it from the past one week . so i was a bit frustrated .
[06:47] <slangasek> gpocentek: gnumeric having a recommends: on evince seems questionable to me; does the relationship really fit the definition of Recommends?
[06:48] <slangasek> gpocentek: but yes, it's ok with me either way
[06:52] <gpocentek> 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] <slangasek> gpocentek: then that agrees with my sense, but the decision is up to you
[06:53] <LaserJock> gpocentek: especially when a lot of other apps can be used to read the pdfs
[06:53] <gpocentek> 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] <TheMuso> slangasek: is this pulse fix something we might want for the alpha? Or are we too far gone to include it?
[09:17] <pitti> slangasek: ask you about what?
[09:17] <pitti> slangasek: usplash? well, I can't really tell; it's hopelessly broken for me either way, I'm afraid :/
[09:21] <pitti> Good morning
[09:25] <StevenK> Morning pitti
[09:31] <cjwatson> morning
[09:31]  * Hobbsee waves
[09:33] <seb128> hello everybody
[09:43] <NCommander> seb128, ping
[09:43] <seb128> hey NCommander
[09:43] <NCommander> seb128, I've got gucharmap packaged
[09:43] <NCommander> Expect for the python bindings
[09:43] <seb128> waouh ;-)
[09:43] <seb128> oh?
[09:43] <NCommander> Which I don't think will be possible unless we kick CDBS
[09:44] <NCommander> It builds the bindings through ./configure
[09:44] <seb128> why ?
[09:44] <NCommander> It doesn't use the nice easy python build system
[09:44] <NCommander> So configure will have to be run multiple times in a proper environment to build bindings for each version
[09:44] <NCommander> (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] <seb128> ah, that, yes, that's unpleasant :-(
[09:45] <NCommander> yeah
[09:45] <NCommander> 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] <NCommander> 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] <seb128> did the soname changed?
[09:46] <NCommander> s/path/pass/s
[09:46] <NCommander> seb128, yeah, I got that, its 7
[09:46] <NCommander> I changed the depend on the dev file so it will install the new library automatically if the -dev package is installed
[09:47] <seb128> ok, so I'm not going to upload that today due to the intrepid alpha 3 freeze
[09:47] <NCommander> seb128, yeah, I got that email :-P
[09:47] <seb128> avoiding soname changes now, that can be disruptive
[09:47] <NCommander> seb128, so you want it without the bindings?
[09:47] <seb128> you can look to gnome-menus for an example
[09:47] <NCommander> (I personally thing it will be very ugly to fix)
[09:47] <NCommander> I did migrate the lp patch which was fun
[09:47] <NCommander> A few variable names changed -_-;
[09:47] <seb128> it builds python binding and uses cdbs
[09:48] <NCommander> seb128, no, building the bindings with CDBS on a normal python package that uses setup is easy
[09:48] <NCommander> I've never seen a package that uses configure to build python bindings
[09:48] <seb128> all the GNOME packages tend to use configure only
[09:49] <NCommander> *fun*
[09:49] <NCommander> Ugh, this is an ugly rules file, even for CDBS
[09:49] <seb128> yes ;-)
[09:50] <seb128> cdbs doesn't make multi-builds friendly
[09:50] <NCommander> ew
[09:50] <NCommander> Yeah
[09:50] <NCommander> I was ...
[09:50] <NCommander> Ew
[09:50]  * NCommander twichs
[09:50] <NCommander> THere is a reason I despise CDBS
[09:50] <NCommander> I'm staring at it right now
[09:50] <seb128> ;-)
[09:50] <seb128> cdbs is great for packaging easily easy things
[09:50] <seb128> ie, most of GNOME where you only need to ./configure && make && make install
[09:51] <NCommander> 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] <realist> mvo: did it let out any magic smoke?
[09:56] <AlexCONRAD> hello, if I wanted to hack glxinfo (from the mesa-utils package), how should I retrieve the source ?
[09:58] <RAOF> apt-get source mesa
[09:58] <RAOF> Also, probably off-topic :)
[09:59] <AlexCONRAD> RAOF: thanks :)
[10:00] <RAOF> Of course, if you wanted to contribute upstream you'd be after cgit.freedesktop.org/mesa/mesa
[10:00] <davmor2> Should compiz kick in on intel gfx cards by default in intrepid?
[10:00] <Chipzz> mvo: power-spike maybe?
[10:01] <Keybuk> The membership of Daniel Holbach (dholbach) in the MOTU (motu) team has
[10:01] <Keybuk> expired.

[10:01] <Keybuk> ...
[10:01]  * Keybuk wonders whether that was supposed to happen
[10:01] <Chipzz> 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] <Chipzz> 486 had a better power-supply apparently :)
[10:02] <Hobbsee> Keybuk: yes, it's deprecated.
[10:02] <Keybuk> Hobbsee: no, it's not
[10:02] <Keybuk> we haven't deprecated the MOTU :p
[10:02] <Hobbsee> oh, we've deprecated ~ubuntu-dev.  i think.
[10:02] <Hobbsee> oops
[10:02] <Hobbsee> it might be fun to deprecate the MOTU, though :P
[10:03] <Keybuk> 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] <davmor2> that'll teach him to go on holiday :)
[10:03] <seb128> bug #197762
[10:03] <Hobbsee> yeah, it annoys me that they only get a week
[10:04] <seb128> on recent comment suggests that using pci=routeirq workaround the issue, on amd duo core system using nvidia chipsets
[10:04] <seb128> is that a known issue? linux bug?
[10:09] <AlexCONRAD> RAOF: no, I'm just trying to alter the glxinfo output...
[10:09] <AlexCONRAD> for testing purpose
[10:09] <AlexCONRAD> RAOF: regarding this issue if you mind: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/250792
[10:10] <mvo> Chipzz: heh :) happend last night too, I suspect something HW releated, I will have to keep a eye on it
[10:11] <NCommander> 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] <seb128> NCommander: because rules are clean and short most of the time
[10:13] <NCommander> 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] <pitti> 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] <pitti> mdz: asking you because it says something about "KnitCorrupt: Knit text:x_Matt_Zimmerman_<matt.zimmerman@canonical.com>" (although that is already very old)
[10:13] <mvo> 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] <mdz> pitti: there's a bzr bug open about that
[10:14] <RAOF> 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] <pitti> mdz: ah, will have a look
[10:14] <NCommander> mvo, maybe its time for a debhelper gnome rule ;-)
[10:14] <cjwatson> pitti: https://answers.launchpad.net/launchpad-bazaar/+question/39693
[10:14] <mvo> debehlper7++ :)
[10:14] <mdz> pitti: I do have a local tree
[10:15] <seb128> NCommander: agreed that multi-builds are ugly when using cdbs
[10:15] <AlexCONRAD> RAOF: I'm just trying to compile to have a dummy hardcoded string in there
[10:15] <cjwatson> 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] <cjwatson> pitti: check/reconcile doesn't help, BTW
[10:15] <mdz> cjwatson: http://people.ubuntu.com/~mdz/bazaar/casper/
[10:15] <pitti> NCommander: well, not more or less ugly than with plain debhelper, it's just that cdbs won't help you with multibuild
[10:16] <SniperBeamer> are ddebs for hardy-backports available somewhere?
[10:16] <mdz> pitti: bug 246880
[10:16] <pitti> SniperBeamer: I currently don't grab/archive them
[10:16] <NCommander> 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] <mdz> pitti: lifeless said he would try to help with it during the sprint, not sure who he worked with
[10:16] <SniperBeamer> ddebs.ubuntu.com doesn't have them
[10:16] <cjwatson> he worked with me
[10:16] <cjwatson> we only succeeded in making it worse
[10:17] <StevenK> pitti: Could I beg you to source NEW wpeditor?
[10:17] <StevenK> pitti: And you *might* be able to NBS out libgpmg1.
[10:18] <cjwatson> mdz: no, those appear to be matt.zimmerman@canonical.com/casper--main--0, not matt.zimmerman@canonical.com--2004/casper--main--0
[10:18] <mdz> cjwatson: sorry, i meant http://people.ubuntu.com/~mdz/bazaar/matt.zimmerman@canonical.com--2004/
[10:18] <mdz> cjwatson: or http://people.ubuntu.com/~mdz/bazaar/matt.zimmerman@canonical.com/
[10:18] <cjwatson> aha
[10:18] <cjwatson> thanks, might be able to piece the ghosts back together from that
[10:18] <StevenK> Hm. hppa might actually be catching up.
[10:19] <NCommander> StevenK, hppa's toolchain is not happy though
[10:19] <cjwatson> mind you, that means I have to install baz ...
[10:19] <mdz> hooray for never deleting anything
[10:20] <NCommander> seb128, I think its a bad sign when ./configure getting run in the autotools-files stamp -_-;
[10:22] <StevenK> NCommander: It isn't?
[10:23] <cjwatson> this is a relief, I have completely forgotten how to drive baz
[10:24] <NCommander> Anyone can tell me what's wrong with this lintian override?
[10:24] <NCommander> codeblocks binary: script-not-executable usr/share/codeblocks/lexers/lexer_bash.sample
[10:24] <NCommander> (I get this from lintian: W: codeblocks: script-not-executable ./usr/share/codeblocks/lexers/lexer_bash.sample)
[10:25] <pitti> NCommander: it apparently has a hashbang line, but is 0644
[10:25] <NCommander> pitti, no, this needs to be overrided, the .sampe is a data file
[10:25] <NCommander> It has a hasbang, and its needed
[10:25] <NCommander> It's not susposed to be an executable script
[10:26] <NCommander> I'm just trying to figure out why my override file isn't working
[10:27] <pitti> NCommander: if it has a hashbang, why shuoldn't it be executable?
[10:28] <NCommander> 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] <seb128> NCommander: try using "./usr/share/codeblocks/lexers/lexer_bash.sample" in the .lintian?
[10:29] <NCommander> seb128, I had tried it :-/
[10:29] <NCommander> THe only thing that has worked thus far is simply killing the entire wanring
[10:29] <seb128> NCommander: and why do you add "binary"?
[10:30] <seb128> "codeblocks: script-not-executable ./usr/share/codeblocks/lexers/lexer_bash.sample"
[10:30] <seb128> try that?
[10:30] <NCommander> loose the binary line?
[10:30] <NCommander> seb128, cause thats what the documentation says
[10:33] <cjwatson> seb128's suggestion is correct
[10:33] <NCommander> I tried putting it in /usr/share/lintian/overrides/codeblocks to test, I still get the warning
[10:33] <cjwatson> I'm not sure about the binary bit, the lintian documentation does say it's optional
[10:34] <cjwatson> but copying and pasting the output without the initial W: or whatever should work
[10:34] <cjwatson> NCommander: it needs to be in the package itself
[10:34] <cjwatson> Note that Lintian extracts the override file from the (u)deb and stores it in
[10:34] <cjwatson> the laboratory. The files currently installed on the system are not used in
[10:34] <cjwatson> current Lintian versions.
[10:34] <cjwatson> ^- from the lintian manual
[10:34] <NCommander> cjwatson, I was rebuilding the package, ccache makes it loads faster
[10:34] <NCommander> It's just finishing the install rules
[10:49] <NCommander> 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] <seb128> NCommander: did you try to copy what gnome-menus does?
[10:50] <NCommander> seb128, yeah, I can't even make it run the right configure target
[10:50] <NCommander> configure/gucharmap:: $(addprefix configure-stamp-, $(PY_VERSIONS)) - doesn't work (nor does just configure::)
[10:51] <seb128> do you have ".PRECIOUS: configure-stamp-% dbg-configure-stamp-%"?
[10:52] <NCommander> seb128, .PRECIOUS: configure-stamp-% dbg-configure-stamp-%
[10:52] <NCommander> Yup
[10:52] <seb128> can you copy your .diff.gz somewhere?
[10:53] <NCommander> seb128, I can stick it on revu
[10:53] <seb128> just copy the rules on http://paste.ubuntu.com maybe, that will be faster
[10:54] <NCommander> seb128, ok
[10:54] <NCommander> seb128, http://paste.ubuntu.com/29906/http://paste.ubuntu.com/29906/
[10:54] <NCommander> er http://paste.ubuntu.com/29906/
[10:56] <seb128> NCommander: does changing configure/libgucharmap7 to configure/gucharmap makes any difference there?
[10:57] <NCommander> seb128, nope
[10:57] <NCommander> I went through every variation that made sense there
[10:58] <seb128> and what error do you get?
[10:58] <NCommander> seb128, no error
[10:58] <NCommander> 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] <seb128> hum
[11:02] <NCommander> 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] <NCommander> ALthough I'll probably take three or more stabs at it before I give up in frustation and rewrite the rules file
[11:02] <NCommander> and then watch that diff.gz get rejected :-P
[11:03] <seb128> NCommander: you did use "DEB_BUILDDIR := build" but that should make a real difference
[11:04] <NCommander> touch debian/stamp-autotools-files
[11:04] <NCommander> chmod a+x /build/gucharmap/gucharmap-2.23.4/./configure
[11:04] <NCommander> It's not :-P
[11:04] <NCommander> Let me post the build log
[11:05] <seb128> in fact I don't think you need the .PRECIOUS line
[11:05] <NCommander> seb128, I've tried without it
[11:06] <NCommander> seb128, you can scratch your head just like I am
[11:06] <seb128> I hate cdbs multi builds ;-)
[11:06] <NCommander> Just say the word and I'll redo the build file in a sane way ;-)
[11:07] <jcristau> the word
[11:07] <NCommander> jcristau, I need it from my mentor (and the guy who's going to be uploading it :-P)
[11:07] <seb128> NCommander: oh, you have 2 clean targets in this rules
[11:07] <seb128> that's not good ;-)
[11:07] <NCommander> I swear, if that was it
[11:07] <NCommander> I'm going to scream
[11:08] <NCommander> and file a bug against CDBS: "Too ugly to live"
[11:08] <NCommander> *phew*
[11:08] <NCommander> No change in output, still not calling configure with the proper environmental PYTHON variable
[11:11] <seb128> NCommander: ok, please put the diff.gz somewhere ;-)
[11:11] <jcristau> NCommander: damn. :)
[11:11]  * NCommander kicks it onto REVU
[11:12] <seb128> but maybe we should use debhelper for packages which need multi builds
[11:12] <seb128> I would like to figure what is wrong there though
[11:12] <NCommander> 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] <NCommander> seb128, it looks like it should work, right?
[11:13] <seb128> NCommander: yes
[11:13] <NCommander> Or at least, try to build in build
[11:15] <NCommander> seb128, its on its way to revu
[11:15] <seb128> ok
[11:18] <NCommander> seb128, http://revu.tauware.de/details.py?package=gucharmap
[11:18] <NCommander> seb128, ignore the lintian warnings, I hadn't cleared them when I tried to make it do multbuilds
[11:20] <seb128> looking
[11:25] <norsetto> any archive admin that can process bug 248060?
[11:26] <NCommander> seb128, As an aside, codeblocks just made it into the archive, wooo
[11:27] <NCommander> 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] <seb128> NCommander: I can do that yes
[11:27] <NCommander> seb128, that would be awesome if it isn't much trouble
[11:28] <NCommander> seb128, (I'd ask ask for sponsoring for D-Maintainer once I prove to you I can package ;-))
[11:29] <seb128> ;-)
[11:29] <NCommander> wow, I think Launchpad's karma counter has a bug
[11:29] <seb128> NCommander: gucharmap seems to work correctly
[11:29] <NCommander> I just jumped from 2000 to 6671
[11:29] <NCommander> seb128, what, the one I uploaded? It doesn't even build here
[11:29] <NCommander> (unless you undid my rules changes)
[11:29] <seb128> NCommander: at least it calls configure using the correct PYTHON=`which python2.5` etc
[11:30] <NCommander> ....
[11:30] <NCommander> It likes you and not me
[11:30] <seb128> well, it seems to be calling the configure a first one without argument
[11:30] <seb128> then cd build-python-2.5
[11:30] <seb128> and then call it correctly
[11:30] <NCommander> seb128, that's failing for me
[11:30] <seb128> s/first one/first time
[11:30] <NCommander> I thought I needed the PYTHON=* to make that work
[11:31] <NCommander> (and as an aside, what dependency do I need installed then, and added to the control file)
[11:31] <seb128> I moved the --enable-python-bindings to the configure-stamps arguements
[11:31] <seb128> forgot to mention that
[11:31] <NCommander> Ah
[11:31] <NCommander> Yeah
[11:31] <seb128> which means the first configure call doesn't try to do that
[11:32] <seb128> now it fails on gucharmap/gucharmap.h.in not being available
[11:32] <NCommander> seb128, that's pretty ugly, but it does work
[11:32] <NCommander> seb128, well, now that its actually trying to build, I can probably resolve it
[11:32] <seb128> I guess it doesn't like building out of the sc dir
[11:32] <seb128> src dir
[11:32] <NCommander> It probably means a giant search/replace is going to hit every Makefile.am file
[11:33] <NCommander> Cause I don't think there is any way to build this inside the build directory
[11:33] <seb128> why?
[11:34] <NCommander> 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] <NCommander> 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] <NCommander> seb128, any suggestions before I got editing happy on the Makefile.am's?
[11:36] <norsetto> 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] <seb128> NCommander: what is the error exactly?
[11:37] <NCommander> ooh
[11:37] <NCommander> I just got an absolutely sick way to fix this
[11:37] <seb128> 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] <NCommander> But it wouldn't require patching every makefile
[11:37] <norsetto> seb128: after 10 days, yes, there is ....
[11:37] <seb128> norsetto: sorry I was travelling for GUADEC and distro sprint and seems other archive admins have been busy too
[11:37] <seb128> norsetto: why is it urgent?
[11:38] <norsetto> seb128: because if causes ocsigen to ftbfs
[11:38] <seb128> well, that would be nice to fix but it doesn't seem particularly urgent
[11:38] <seb128> I'll do the sync now anyway
[11:39]  * norsetto hugs seb128
[11:39] <NCommander> seb128, I think cp -r * build-$* might be excessively too ugly to live
[11:40] <seb128> NCommander: I tried to "mkdir build; cd build; ../configure" and that seems to work, weird
[11:40] <NCommander> My solution was to simply copy the source directory into the build directory ;-)
[11:41] <NCommander> seb128, CDBS is probably doing something rather nasty to the envornment thats causing it not to work
[11:41] <seb128> feel free to rewrite the rules using debhelper if you think that would make things easier and cleaner
[11:42] <NCommander> seb128, O_o; what made you give up CDBS and let me rewrite the rules :-P
[11:43] <NCommander> 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] <seb128> I don't care that much about using cdbs for multibuild, that's often ugly
[11:43] <seb128> maybe there is some srcdir that need to be changed to builddir in a makefile
[11:44] <NCommander> seb128, well, at this point, I actually got it building as a multibuild
[11:44] <seb128> oh?
[11:44] <NCommander> Well, mostly, I'm tweaking it as it fails, but it appears to now be somewhat working
[11:45] <NCommander> seb128, http://paste.ubuntu.com/29925/ - take a look at what I did
[11:45] <seb128> bah
[11:45] <seb128> that's ugly
[11:46] <NCommander>  You've got to give me points for thinking outside the box ;-)
[11:46] <seb128> what breaks it is the srcdir=. given to the configure
[11:47] <NCommander> so just force srcdir=..?
[11:48] <seb128> that would work I guess, but I'm trying to figure why srcdir=. is used
[11:48] <zyga> mvo: hello, do you mind being subscribed to bug 105219?
[11:49] <zyga> I believe that bug is now fixed, I added a comment at the bottom of the page
[11:49] <seb128> NCommander: ah, that's because you forgot the "DEB_BUILDDIR := build"
[11:50] <seb128> NCommander: adding that to the rules make it work correctly
[11:52] <NCommander> argh, its now not working for me
[11:52] <seb128> is "there is no sound on intrepid when pulseaudio is running" a known issue?
[11:52] <NCommander> I see python go in, and then configure goes boom
[11:53] <NCommander> seb128, got any idea why it can't link against libpython?
[11:53] <mvo> zyga: sure, please subscribe me
[11:56] <seb128> NCommander: not really, looking at it
[12:06] <NCommander> seb128, any luck?
[12:14] <seb128> NCommander: no, I'm a bit puzzled by this one
[12:16] <NCommander> seb128, yeah, the libtool line looks like it should work
[12:16] <seb128> NCommander: it's due to the autoreconf patch
[12:17] <seb128> not sure what in it though
[12:17] <NCommander> hrm
[12:17] <seb128> moving the patches directory away make it work
[12:17]  * NCommander just reruns autoreconf
[12:17] <seb128> btw the patch should be an autoconf one
[12:17] <seb128> no need to run automake etc in this case
[12:17] <seb128> only the configure needs updating
[12:18] <pitti> wow
[12:18] <pitti> I mean, WOW!
[12:18] <pitti> intrepid desktop booting fine for me under intrepid kvm
[12:18] <pitti> including usplash
[12:18] <seb128> ;-)
[12:18] <pitti> something is clearly wrong here...
[12:19] <seb128> NCommander: just running autoconf produces a 20 lines patch and doesn't break the build
[12:19] <seb128> NCommander: running autoreconf is looking for trouble ;-)
[12:20] <NCommander> Well
[12:20] <NCommander> ...
[12:20] <pitti> 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] <seb128> NCommander: btw you want to change the gmenu mention in the rules too
[12:20] <seb128> the egrep command
[12:20] <NCommander> seb128, yeah, that already got killed
[12:20] <pitti> soren: at some point we had a scaling problem with the vmmouse driver; did that creep back in somehow?
[12:20] <pitti> soren: (I guess it uses vmmouse?)
[12:22] <seb128> NCommander: seems to build fine now
[12:22] <NCommander> seb128, What a headache
[12:22] <NCommander> Between autoconf and CDBS ... I apperiate you taking so much time in helping to resolve this
[12:22] <seb128> np ;-)
[12:22] <seb128> thank you for the work you put on updating this package!
[12:22] <NCommander> seb128, its not a problem
[12:23] <NCommander> seb128, if it builds, now its just a matter of install rules, and control updates
[12:23] <seb128> right
[12:23]  * NCommander flips through the rules for python bindings
[12:23] <NCommander> I'm bound to get this wrong two or three times ;-)
[12:24] <NCommander> seb128, so what's the next headache you got queued up?
[12:24] <soren> pitti: Oh, i386 boots fine? That's... er... unexpected :)
[12:25] <NCommander> pitti, an actual i386 boots O_o?
[12:25] <NCommander> WTF?
[12:25] <cjwatson> soren: (boots for me too)
[12:25] <seb128> NCommander: you mean in gucharmap?
[12:25] <soren> pitti: I'm having a few different interesting issues with the new Xorg. I've not yet quite worked out if kvm or Xorg is to blame.
[12:25] <pitti> soren: I just installed libvirt-bin again and tried in virt-manager; now I'm back to the problem I have had for some weeks, in that the boot in virt-manager is painfully slow and just times out
[12:25] <soren> cjwatson, pitti: On i386 hosts?
[12:25] <NCommander> seb128, updated packages for desktop, you seem to have a list of evil packages you keep for your mentees to make them run and hide
[12:25] <cjwatson> soren: yes
[12:26] <pitti> soren: yes
[12:26]  * NCommander can't believe that actually works O.o;
[12:26] <soren> Hm. Ok.
[12:26] <pitti> so with just plain "kvm -m 512 -cdrom" the boot works and roadrunner-mouse
[12:26] <seb128> NCommander: those were the harder ;-) other updates are rather standard ones
[12:26] <pitti> with virt-manager -> initramfs prompt
[12:26] <cjwatson> I have a similar mouse problem as pitti
[12:26] <soren> pitti: I don't know if the current X stuff figures out that it should be using vmmouse.
[12:26] <NCommander> pitti, should I go get my 386SX and try it ;-)
[12:26] <cjwatson> I can't even *see* the mouse, it just zips from one corner to the next
[12:26] <NCommander> seb128, if you call this "hard", then I laugh in the face of danger!
[12:26] <soren> cjwatson, pitti: Does the Xorg.log mention vmmouse at all?
[12:26] <NCommander> It was more frustating then hard
[12:26] <pitti> NCommander: well, not *that* kind of i386 :)
[12:27] <NCommander> pitti, d'oh :-P, be more specifc
[12:27] <pitti> soren: how do I send ctrl+alt+f1 or ctrl+alt+backspace with plain kvm?
[12:27] <seb128> NCommander: there is still the "make an epiphany-browser-snapshot package to build epiphany-webkit from svn" on the list of fun things to do if you are looking for trouble, but that's in no mean a priority
[12:27] <cjwatson> soren: yeah, "vmmouse enabled" at the end
[12:27] <soren> pitti: Heh... ctrl-alt-2, "sendkey ctrl-alt-f2", ctrl-alt-1
[12:27] <NCommander> seb128, I'll probably extend REVU to have apt-get source support before I do that
[12:27] <cjwatson> (bear with me, I'm doing another rather delicate test here)
[12:28] <seb128> NCommander: well, usually package updates are really easy, ie run dch, update build-depends, build, test, upload
[12:28] <seb128> NCommander: so those were already "hard" updates ;-)
[12:28] <NCommander> seb128, you've been lucky. my upstream packages like to play change the build system every release
[12:28] <pitti> soren: booting in kvm again
[12:29] <seb128> yeah, GNOME is nice for that
[12:29] <pitti> soren: ctrl+alt+2> nice, didn't know about that
[12:29] <seb128> ok, lunch time, be back in a bit
[12:30] <soren> pitti: You can get all sorts of cool info there.
[12:30] <pitti> wow, there are serial and parallel consoles, too
[12:30] <soren> pitti: "info registers" for instance.
[12:32] <pitti> hm, it didn't particularly like Alt+f2 "gksu killall gdm"
[12:32]  * pitti tries again
[12:35] <NCommander> woo, I got python patches
[12:38] <pitti> soren: confirmed; s/vmmouse/mouse/ in xorg.conf gets me back to sanity
[12:38] <AlexCONRAD> is there a way to see which graphic driver is currently used by xorg ? I know there's xorg.conf, but I'd like to make sure my changes has been taken in account.
[12:38] <pitti> AlexCONRAD: /var/log/Xorg.0.log tells you
[12:39] <AlexCONRAD> pitti: thanks
[12:40] <soren> pitti: That is *so* backwards.
[12:40] <soren> pitti: vmmouse used to be the sane one.
[12:41] <pitti> cjwatson: when you were trying kvm, did you call kvm from a shell, or used virt-manager?
[12:41] <cjwatson> shell
[12:41] <pitti> ah
[12:41] <cjwatson> virt-manager is too much mousing around
[12:41] <AlexCONRAD> hummm, it seems to load both "ati" and "radeon"
[12:41] <AlexCONRAD> (I've set ati)
[12:41] <soren> pitti: It uses a backdoor to provide absolute coordinates so that it can place the mouse pointer where the host mouse pointer is. Wonder why that'd break.
[12:41] <pitti> cjwatson: how do you create images then? qemu-img?
[12:42] <cjwatson> pitti: dd
[12:42] <pitti> soren: in non-grab mode, I don't see the pointer at all; in grab mode (explicitly pressing ctrl+alt), I get the fast one
[12:42] <pitti> cjwatson: oh, that works? no magic signatures? nice
[12:42] <cjwatson> all I need is a file full of zeroes, I don't need a complicated UI to give me that
[12:42] <cjwatson> soren: bug 195431 was fix-committed three months ago. What is its status?
[12:42] <cjwatson> s/vmmouse/mouse/g fixes it for me too
[12:42] <soren> cjwatson: qemu-img will do that for you, too.
[12:43] <soren> cjwatson: Without actually eating all the disk space. It just creates a sparse file.
[12:43] <cjwatson> however, mouse doesn't do host mouse pointer tracking, as you say
[12:43] <cjwatson> it works fine when I grab the mouse
[12:43] <cjwatson> soren: *shrug* I'm usually happier to take the I/O hit up-front
[12:43] <cjwatson> and also not have weird shit happen when I run out of disk in the middle of a test run
[12:44] <pitti> me too; virt-manager seems to allocate it all for real, too
[12:44] <soren> pitti: There's a checkbox to enable/disable that.
[12:44] <pitti> ah :)
[12:44] <soren> pitti: Right beneath the box where you enter the amount of space.
[12:44] <soren> "allocate disk space now" or some such.
[12:44] <soren> cjwatson: 195431 went down the drains as upstream changed a whole bunch of stuff, so my patch fell apart.
[12:44] <pitti> soren: so, while I'm fine with running from the command line, I'm still curious why virt-manager stopped working; do you get that, too?
[12:45] <soren> pitti: Which part of virt-manager exactly?
[12:45] <pitti> soren: I mean that the cd boots so exceptionally slow (and hangs in initramfs prompt)
[12:46] <soren> pitti: There's a chance it's falling back to emulated mode (qemu style).
[12:46] <cjwatson> soren: can you make its status be truthful, then? :)
[12:46] <soren> pitti: Are you connected to qemu:///system or qemu:///session?
[12:46] <pitti> soren: system usually
[12:47] <soren> pitti: Hmm... That shouldn't be the case than.
[12:47] <soren> s/than/then/
[12:48] <soren> cjwatson: Heh... Yes, sorry, just did.
[12:49] <Martiini> has there been alfa 3 yet for intrepid ? My intrepid doesnt upgrade for some reason
[12:50] <soren> pitti: But no, I've not seen the issue you describe.
[12:51] <Martiini> https://wiki.ubuntu.com/IntrepidReleaseSchedule says intrepid alpha 3 release date 24 july .. (which is today) but I dont get any upgardes .. anyone ??
[12:55] <cjwatson> Martiini: alphas have very little to do with whether you get upgrades
[12:55] <cjwatson> Martiini: and no, it hasn't been released yet, some desktop CD problems
[12:56] <Martiini> okidoki
[12:59] <Martiini> anyone know what distributions does Linus Torvalds use
[13:00] <cjwatson> I'm afraid that's off-topic here
[13:01] <Hobbsee> Martiini: and it's be really nice if you didn't cross-post on irc.
[13:01]  * mpt has sound!!!!!
[13:02] <k0p> lol
[13:04] <seb128> mpt: did you stop pulseaudio to get sound?
[13:04] <mpt> seb128, no, all I did was turn on the computer
[13:04] <mpt> How do I tell whether pulseaudio is running?
[13:05] <seb128> ps ax | grep pulseaudio?
[13:05] <seb128> or use the system monitor
[13:05] <mpt> (I'd be surprised if this was a pulseaudio problem, because the problem began in Hoary)
[13:05] <persia> mpt: pulseaudio --check
[13:05] <seb128> ok, I've no sound in intrepid when pulseaudio is running
[13:05] <seb128> and it seems I'm not the only one
[13:06] <mpt> pulseaudio and pulseaudio/pulse/gconf-helper are both running
[13:06] <seb128> if anybody wants to work on the issue and needs details let me know ;-)
[13:06] <mvo> seb128: I have no sound in intrepid too, however if I boot into the 2.6.24 kernel it works again
[13:06] <seb128> mvo: if you stop pulseaudio do you get sound?
[13:06] <mpt> And if anyone wants to help debug my problem, it's bug 80344 ;-)
[13:07] <persia> That's not a good bug title :)
[13:07] <mvo> seb128: I haven't tested that yet, I'm in 2.6.24 currently
[13:07] <seb128> mvo: ok, if you try let me know
[13:07] <persia> mpt: Are you perhaps sending output to your PC Speaker, rather than your preferred card?
[13:09] <mpt> persia, if there's anything I should check when it stops working in a week or two, it would be great if you could post specific instructions in the bug report (e.g. I don't know how to tell whether output is being sent to a "PC speaker")
[13:11] <persia> mpt: catch me when your sound breaks, and we'll interactively fix it.  I'm completely certain that your bug report is a question, as the issues that caused sound to break in 5.04 and the issues that cause sound to break in 8.10 are different (unless you are encountering atypical problems).
[13:11] <seb128> mpt: do you by any chance know what is the bug number for "bug pages have no informations about the package versions"? I'm pretty sure there was a bug for that, it was fixed I think and it's back now
[13:11] <mpt> persia, ok, thanks for the offer
[13:12] <seb128> I can't find the bug number though
[13:12] <mpt> seb128, mouse over the package name
[13:12] <mpt> Now there's information on versions for *all* the packages in a bug report, not just the one of them
[13:12] <seb128> whaouh, that's really not obvious
[13:12] <seb128> but thanks
[13:13] <seb128> mpt: right, which is not really good, I usually care about versions when I'm reading a bug, when I'm on the bugs list
[13:13] <seb128> that's especially annoying when the guy say "I'm using version n.m.o" and you want to know what ubuntu version is shipping this one
[13:14] <seb128> do you know if there is already a bug requesting to have this table back on the normal bug pages,
[13:14] <seb128> ?
[13:17] <Hobbsee> seb128: you're the 50th-odd person to say that, but it hasn't changed anything so far.
[13:17] <mpt> what the hell?
[13:18] <Hobbsee> unfortunately :)
[13:18] <mpt> Hobbsee, we had an extensive discussion about this, exactly what information you wanted and didn't want, and I posted a mockup on the bug report.
[13:18] <Hobbsee> oh, bah.
[13:18] <mpt> Where did you say "No, that's not enough, we need the box"?
[13:18] <Hobbsee> i meant the comments about it being really not obvious
[13:18] <Hobbsee> (apologies, i'm badly multitasking here)
[13:19] <mpt> Is there a bug report about that?
[13:19] <Hobbsee> i'm not sure.
[13:20] <seb128> I was pretty sure there was one, but I can't find it now
[13:20] <seb128> I'll open a new one
[13:20] <seb128> the current thing is not obvious and not enough
[13:20] <mpt> ok
[13:20] <seb128> and it forces me to open the overview page a lot and wait for it to load just to know what ubuntu version people are using
[13:21] <Hobbsee> seb128: rmadison, surely.  it's quicker.
[13:21] <seb128> Hobbsee: I tend to like working from the web interface
[13:21] <seb128> having the summary on the side was very handy
[13:21] <Hobbsee> seb128: ah, come to think of it, i guess you have fast connections there too.  and indeed, i agree with you.
[13:24] <mpt> hm, I wonder how we could present it mot obviously but still in a context-independent way
[13:24] <mpt> er, *more* obviously
[13:24] <mpt> Perhaps an "(i)" icon after the package name?
[13:25] <seb128> mpt: bug #134220
[13:25] <seb128> mpt: should I reopen this one or open a new bug?
[13:26] <Hobbsee> mpt: i'm not sure you can.  you want to present it so it's findable, yet you don't want people to see it without specifically jumping through hoops to find it.
[13:27] <Hobbsee> you want it to vanish, yet you want to make it more obviously visible.
[13:27] <Hobbsee> this seems counterintuitive.
[13:28] <mpt> seb128, a new one please. The page does have information about the current package version. Please be specific about whether its current placement is too hard to get to, not obvious for the people who need to see it, or what.
[13:31] <NCommander> seb128, gucharmap is lintian-cleanish with python-gucharmap built. Its sitting in my PPA
[13:38] <seb128> mpt: bug #251479, description is alright?
[13:38] <seb128> NCommander: good, looking to that in a minute
[13:39] <NCommander> seb128, I scare myself on what I can do when I get bored/motivated
[13:39] <seb128> ;-)
[13:43] <Wubbbi> bug 249850
[13:55] <sistpoty|work> soren: can you specify which live cd and kvm combination cause x to hang? (bug #251480)
[13:55] <sistpoty|work> soren: as I tried with yesterdays desktop-live and a hardy kvm, which at least didn't cause x to hang
[13:56] <stgraber> sistpoty|work: if by hang, it's getting a black screen and nothing else, I have reproduced that with Intrepid's kvm on an amd64 host with an amd64 Intrepid Desktop CD
[13:56] <stgraber> sistpoty|work: the same with an i386 Intrepid desktop CD works fine (well, no mouse but that's another issue)
[13:56] <sistpoty|work> stgraber: ah, I tried only i386 desktop on amd64 hardy kvm
[13:57] <stgraber> try amd64 desktop, i386 have always been working for me
[13:57]  * sistpoty|work will do so later today
[14:01] <norsetto> seb128: thx seb, you know I love you, don't you?
[14:03] <seb128> norsetto: you're welcome ;-) love might be a bit strong but thanks :-p
[14:12] <pkern> Could updates to some stable suite be copied from ppas now?  Just curious.
[14:12] <tkamppeter> Riddell, ping
[14:13] <Riddell> hi tkamppeter
[14:17] <tkamppeter> Riddell, we have started the telecon about the printing dialog ...
[14:17] <persia> pkern: Even were it possible, it's dangerous to do a full copy rather than a sync given that build-dependencies may have updated.  Also, there's the version number thing.
[14:18] <ScottK> pkern: I think an archive admin could do it.  I know it's possible for them to copy from PPAs to the development release.
[14:18] <norsetto> persia: is there some kind of script/utility you use when giving IRC lessons?
[14:18] <persia> norsetto: No.  Why?
[14:18] <norsetto> persia: ok, just to avoid copying and pasting from a prepared text
[14:19] <cjwatson> copy from ppa> it would have to be a source-only copy
[14:19] <persia> norsetto: I am a firm believer that stock replies are typically incorrect.
[14:19] <cjwatson> and I think it would be better to copy to -proposed first, have it build there, and then copy to -updates
[14:19] <cjwatson> although I suppose copying from a ppa that was basically just built against hardy would be OK
[14:19] <cjwatson> (inc. binaries)
[14:19] <pkern> cjwatson: Sure, what I meant.  So that's possible but people should not use ppa versioning then?
[14:20] <cjwatson> I don't think I care about versioning
[14:20] <cjwatson> seems like a red herring
[14:20] <norsetto> persia: no stock replies, just lines of commands
[14:20] <cjwatson> let's put it this way: it's technically possible, but we would have to think about whether it's desirable in particular cases
[14:21] <persia> norsetto: Oh, like for teaching a class?
[14:22] <ScottK> pkern: I'd suggest for some people for a very small value of some.
[14:22] <norsetto> persia:I thought it was clear when I said "when giving IRC lessons" :-)
[14:25] <persia> norsetto: Right.  My misunderstanding.  Copy/paste from prepared text seems like a good idea: I usually don't prepare well enough beforehand to be able to take advantage of that.
[14:25] <norsetto> persia: ok, thx
[14:27] <soren> sistpoty|work: Oh, it's only amd64/amd64? That's even more interesting.
[14:28] <sistpoty|work> soren: looks like it
[14:45] <pitti> lamont: thanks for the chroots!
[14:47] <emgent> uhmm..
[14:47] <emgent> https://launchpad.net/ubuntu/+builds?build_text=koffice2&build_state=all
[14:47] <emgent> some idea about it ?
[14:47] <emgent> i386 build of koffice2 1:1.9.96.0~that.is.really.1.9.95.8-1ubuntu2 in ubuntu intrepid RELEASE ?
[14:48] <lamont> pitti: no worries
[14:48] <emgent> all broken
[14:48] <emgent> argh
[14:48] <cjwatson> emgent: seems to fail to build in a completely normal way that the uploader should fix
[14:48] <cjwatson> http://launchpadlibrarian.net/15971937/buildlog_ubuntu-intrepid-i386.koffice2_1%3A1.9.96.0~that.is.really.1.9.95.8-1ubuntu2_FAILEDTOBUILD.txt.gz
[14:50] <cjwatson> 1:1.9.96.0~that.is.really.1.9.95.9-1ubuntu1.3 looks like it should fix this but doesn't seem to have been tried yet
[14:51] <cjwatson> I'd give it slightly more than 46 minutes if I were you
[14:51] <cjwatson> (the time since upload, so far)
[15:24] <sistpoty|work> soren: I'm just testing the current desktop-live (amd64) within faumachine, but I get OOPSes before even coming anywhere close to x...
[15:26] <soren> sistpoty|work: I'm not quite sure what to make of that..
[15:27] <sistpoty|work> soren: do you see anything similar from kvm? (when starting w.o. serial konsole, I don't have any means to get any debug info from within faumachine)
[15:27] <soren> faumachine doesn't emulate a vga adapter?
[15:28] <sistpoty|work> soren: it does, (slightly different implementation of the gd5442)
[15:28] <sistpoty|work> soren: however it just turns blank at some point
[15:28] <soren> Did you try disabling usplash?
[15:29] <sistpoty|work> soren: yes, tried both with and without
[15:29] <soren> Oddness.
[15:37]  * soren kicks firefox
[15:39] <soren> Ok, seeing as input fields in firefox is the only place where ctrl-w doesn't mean "please remove the word immediately preceeding the cursor", but rather "Oh, please firefox. Won't you please close the tab I've spent half an hour entering stuff into and just nuke all the stuff I did?"....
[15:39] <soren> How do I change shortcut?
[15:40] <pitti> soren: ctrl+shift+t is your friend
[15:40] <seb128> bah, pitti ruined my "use epiphany-browser rather" there ;-)
[15:41] <Mithrandir> seb128: epiphany still doesn't have ctrl-tab for switching tabs.
[15:41] <pitti> "unclose tab" is the best function EVAR
[15:41] <soren> pitti: What about the info i've typed in?
[15:42] <ScottK> pitti: Do you think Bug 251472 is SRU worthy?  The fix has just been uploaded to Debian.
[15:42] <soren> seb128: I used to use epiphany, but the libffi transition made that rather hard for a while. Now I've just gotten used to firefox, I guess.
[15:42] <pitti> soren: uh, seems that isn't kept with LP, too bad
[15:42] <pitti> ScottK: if it's an easy patch, sure
[15:42] <soren> If it were just LP, that'd be fine.
[15:42] <soren> This is sourceforge...
[15:43] <ScottK> pitti: OK.  Thanks.
[15:43] <soren> Anything that keeps me there for more than just a few seconds is by definition BAD.
[15:43] <pitti> lol
[15:44] <pitti> soren: admittedly ffox is quite consistent with GNOME wrt. ctrl+w
[15:44] <pitti> gnome-terminal is the exception, not the rule
[15:45] <pitti> soren: if it was really a long text, maybe you are lucky with gcore and "strings core | grep"...
[15:45] <soren> pitti: I've actually done that once.
[15:45] <soren> pitti: I was being particularly stubborn that day :)
[15:46] <sistpoty|work> hm.. interesting... hardy kvm gives me after starting gdm: "BUG: soft lockup - CPU#0 stuck for 61s! [Xorg:5724]"... no I'm puzzled even more
[15:46] <pitti> soren: just tried that, that actually works :)
[15:59] <pitti> seb128: no response at all in bug 205483
[16:00] <seb128> pitti: yeah, most of bugs got no replies
[16:00] <pitti> :(
[16:01] <seb128> should we just block updates on lack of feedbacks?
[16:01] <seb128> the diffs are pretty small and I've been running the updated version for 10 days before upgrading my laptop to intrepid
[16:01] <pitti> well, some confirmation that the real .deb works would be appreciated
[16:01] <pitti> see the glib issue...
[16:01] <pitti> seb128: the version from hardy-proposed, or your local build?
[16:01] <seb128> both
[16:02] <pitti> ok
[16:02] <seb128> my laptop has the local build
[16:02] <seb128> and my desktop got the official updates
[16:02] <pitti> seb128: maybe you can add comments to the packages which you tested (the archive .debs)?
[16:02] <seb128> that can wait for next week
[16:02] <pitti> and mark them as v-done
[16:02] <seb128> I'll try to kick pedro and get him to comment on those
[16:02] <seb128> but I think he's on holidays at the moment
[16:04] <gaspa> ﻿seb128, pitti: could help a script that lists nbs that could be removed?
[16:05] <pitti> gaspa: for finding cycles or hppa-only stuff? sure
[16:05] <pitti> gaspa: you mean you have one which does some intelligent checks based on http://people.ubuntu.com/~ubuntu-archive/NBS/ ?
[16:05] <gaspa> pitti: it looks for nbs that hasn't anymore dep. or build-dep.
[16:05] <gaspa> yep
[16:05] <gaspa> it start from that page.
[16:06] <cjwatson> isn't that just iterating down that page and looking for zero-sized entries? :)
[16:06] <pitti> but that information is already there?
[16:06] <StevenK> cjwatson: Yes :-)
[16:06] <cjwatson> that's all I do when processing it, it's trivial
[16:06] <pitti> I regularly wget -np -r that page, and do a find -empty | xargs lp-remove-package.py
[16:06] <pitti> the tricky bit is to evaluate the nonemtpy ones :)
[16:06] <StevenK> I'm getting scared by all the KDE bits on there
[16:07] <seb128> I do the "for p in $(find -empty | sed 's_^./__'); do lp-remove-package.py ..." listed on the wiki
[16:07] <pitti> sometimes there are cycles (two NBS depend on each other), sometimes it's just hppa not catching up
[16:07] <gaspa> it should handle cycles... not hppa, still
[16:07] <StevenK> pitti: And sometimes it requires 27 uploads. :-)
[16:07] <pitti> yeah
[16:08]  * StevenK did 20 odd uploads for libgpmg1 recently
[16:08] <cjwatson> I think it's worth avoiding the kernel NBSes at the moment
[16:09] <pitti> BenC: what's the grand plan to solve this, BTW? ^
[16:09] <StevenK> Ah ha. The reason for all of the KDE stuff is ichthux-desktop.
[16:09] <pitti> BenC: I haven't removed all teh NBS bits from linux-meta, but at some point something needs to provide them again
[16:09] <StevenK> pitti: Such as lpia and co, or is this something else?
[16:09] <pitti> StevenK: that was another case I ignored, since i-d depends on a ton of NBS stuff
[16:09] <BenC> pitti: NBS?
[16:10] <pitti> BenC: "not built from source"
[16:10] <persia> I've heard that ichthux-desktop is planned for an update later this week (although my news is from last week)
[16:10] <gaspa> pitti: well, if you want to take a look it's here:https://code.edge.launchpad.net/~gaspa/+junk/ubuntu_qa_tools
[16:10] <StevenK> persia: Who do we bleat at about it?
[16:10] <pitti> BenC: i. e. nothing builds linux-image-{lpia,openvz} ATM
[16:10] <BenC> pitti: ah, I'll get back to you after I get unionfs in line
[16:10] <BenC> pitti: that's fine
[16:10] <StevenK> NBS is large enough to scare small children at the moment.
[16:10] <persia> StevenK: txwikinger2 and raphink I think (or try #ichthux)
[16:11] <pitti> BenC: unionfs? I thought that finally died (it had it coming..), and replaced by aufs?
[16:12] <BenC> pitti: tell that to the aufs that's holding up alpha3 :)
[16:12] <pitti> sledgehammer.apply(aufs)
[16:14] <StevenK> BenC: If you have any plans for a -lpia{,compat} meta for Intrepid, I'd love to hear it.
[16:14] <cjwatson> pitti: conjecture is that aufs broke it
[16:15] <pitti> 'it'?
[16:15] <cjwatson> so my sympathy levels for people promoting it are extremely low at the moment :)
[16:15] <cjwatson> pitti: yes
[16:15] <StevenK> I think that's the main reason for leaving NBS alone for a little while -- kernel fun-ness, and ichthux-desktop
[16:15] <BenC> StevenK: lpia will be provided by another package
[16:15] <cjwatson> pitti: bug 251223
[16:15] <laga> aufs is broken or unionfs is broken?
[16:15] <pitti> I had ubiquity left installing, and after ten minutes I looked back at kvm, which was just black and crashed
[16:15] <pitti> might be it, yes :)
[16:15] <cjwatson> laga: we're using aufs, and the desktop CD is busted in a bizarre kernelish way
[16:16] <laga> ooh :(
[16:16] <cjwatson> laga: we are currently trying to revert to unionfs
[16:16] <cjwatson> since this is the first time aufs has been seriously tested in the Ubuntu context
[16:16] <pitti> ugh, fun
[16:16] <cjwatson> admittedly, correlation != causation
[16:16] <StevenK> BenC: Where another package is one provided by the kernel team, or someone stepping up to do it?
[16:16] <laga> maybe a newer aufs snapshot would help, that guy releases every monday.
[16:16] <laga> cjwatson: yeah.
[16:16] <BenC> StevenK: combination of kernel+mobile teams providing it
[16:17] <cjwatson> laga: that is not encouraging
[16:17] <StevenK> Heh
[16:17] <cjwatson> no serious software engineer likes something where you have to be on the bleeding edge or it blows up
[16:17] <pitti> is aufs upstream, or external?
[16:17] <cjwatson> external
[16:17] <laga> cjwatson: well, it was working fine for me in hardy. i was merely suggesting trying a newer snapshot to see if it's fixed there - backporting might help then
[16:18] <laga> external. upstream doesn't like stacking file systems
[16:18] <cjwatson> laga: if unionfs can be made to work, that pleases me far more than yet more bleeding-edge code
[16:18] <cjwatson> stable > shiny
[16:18] <laga> at least not in the way it's implemented by aufs/unionfs.
[16:18] <pitti> I had quite a long argument with Arjan about out-of-tree drivers, and unionfs was my prime example
[16:18] <StevenK> I bet cjwatson doesn't use compiz either.

[16:18] <cjwatson> StevenK: you would win that bet
[16:18] <StevenK> cjwatson: :-)
[16:19] <pitti> StevenK: nobody else is (except seb128, of course); it's not the default in intrepid :)
[16:19] <Hobbsee> \o/ shiny!
[16:19] <StevenK> Awww
[16:19] <laga> cjwatson: i guess i should mess around with mythbuntu-diskless on intrepid to check if i can reproduce your oddities with that setup
[16:19] <pitti> thanks to a combination of breakage in gnome-session, new X, and the X drivers
[16:23] <ScottK> pitti: Debdiff for hardy-proposed for Bug 251472 is in the bug.  How are you with that for upload?  I've already asked to have the test case added to the bug.
[16:23] <pitti> ScottK: oh, need a sponsor?
[16:23] <ScottK> piI
[16:23] <ScottK> Urgh
[16:24] <pitti> the same just happened to kees
[16:24] <pitti> did intrepid break the 't' key? :-)
[16:24] <ScottK> pitti: I'll sponsor it, just I want to make sure since it's in Main, ubuntu-sru is happy with it.
[16:24] <ScottK> pitti: No, this is my desktop I'm typing on.  It's still Dapper.
[16:25] <ion_> π-tti
[16:26] <pitti> ScottK: haven't thorougly read the patch, but size and shape-wise it looks ok to me
[16:26] <pitti> and it apparently got tested
[16:26] <ScottK> The person who did the patch is Upstream and Debian Maintainer, so I tend to trust it.
[16:26] <pitti> right
[16:27]  * pkern glances into the round.
[16:28] <pitti> hello pkern!
[16:28] <pkern> Hi pitti (:
[16:36] <ScottK> pitti: I guess I'll focus on the 'looks ok to me' part of that and upload it.
[16:38] <pranith> hello
[16:38] <pranith> !start
[16:38] <pranith> !getstarted
[16:38] <pranith> !ubuntu
[16:38] <pranith> !motu
[16:38] <pranith> !help
[16:38] <pitti> what's that, ubottu's test suite?
[16:39] <StevenK> Hah
[16:39] <persia> pranith: If you'd like to get started in Ubuntu Development, you might find #ubuntu-motu a better forum.
[16:39] <pranith> persia, thank you :)
[16:39] <cjwatson> pranith: please don't play with the bot in here
[16:39] <pranith> cjwatson, okies
[16:40] <cjwatson> or in channels, in general
[16:43] <pitti> ember, tseliot: FYI, http://bazaar.launchpad.net/~jockey-hackers/jockey/trunk/revision/346 fixes the "multiple nvidia drivers are in use" problem properly
[16:44]  * tseliot has a look at pitti's new code
[16:48] <tseliot> ﻿pitti: what do mean by 'mesa-vanilla'?
[16:48] <pitti> tseliot: it is one of the mock packages which exist in the test suite sandbox
[16:49] <pitti> tseliot: I have a few kernel modules (vanilla, chocolate, cherry, etc.), and a few packages (coreutils, mesa-vanilla, mesa-std, pretzel) to play around with
[16:49] <pitti> tseliot: see tests/sandbox.py, fake_modinfo, fake_sys, fake_pkg, and fake_db
[16:49] <pitti> s/fake_pkg/&info/
[16:50] <pitti> tseliot: and TestOSLib implements the package and module interface to use the fake stuff
[16:50] <pitti> that way I can write tests for hardware detection, driver mapping, and package handling without assuming anything about the real hardware, or OS
[16:51] <tseliot> ﻿pitti: yes, that's a good idea
[16:51] <tseliot> ﻿pitti: would you like me to pull the new code and test it here?
[16:52] <pitti> tseliot: sure, if you wish, but I'm pretty confident that it works
[16:52] <pitti> tseliot: let me merge to the ubuntu branch and push
[16:52] <tseliot> ﻿pitti: ok, in the meantime I'll boot into Intrepid
[16:55] <pitti> tseliot: pushed
[16:56] <tseliot> pitti: I'm back
[16:56] <pitti> tseliot: pushed
[16:58] <tseliot> pitti: pulled and installed
[16:58] <pitti> . o O { that SO much beats sending patches over pastebin...}
[16:59] <tseliot> pitti: definitely.
[16:59]  * tseliot tries to install the driver
[16:59] <tseliot> pitti: same problem with the backend
[17:00] <pitti> tseliot: which problem? drivers still shown as 'used'?
[17:00] <tseliot> pitti: no, drivers are not installed
[17:00] <tseliot> pitti: shall I start the backend in debug mode?
[17:01] <pitti> tseliot: hang on
[17:01] <pitti> tseliot: wasn't that the problem with the $PATH not set? I fixed that yesterday...
[17:01] <pitti> tseliot: yes, please try to start in debug mode
[17:03] <tseliot> pitti: ok, it's installing the packages now
[17:04] <tseliot> pitti: the package is installed and in use while others are not. It works
[17:04] <pitti> good
[17:04] <pitti> tseliot: so if you kill the backend and let it auto-spawn, package isntallatin/removal doesn't work?
[17:05] <tseliot> pitti: shall I keep Jockey's gui open?
[17:05] <pitti> shouldn't matter
[17:05] <pitti> it will just cause respawns as soon as you hit it with the mouse (on a driver)
[17:06] <pitti> but that's what you want, so it's ok :)
[17:06] <pitti> tseliot: let me commit a debugging improvement I temporarily added yesterday
[17:07] <tseliot> pitti: now that I have stopped the backend without closing the GUI, it seems to work well.
[17:08] <tseliot> I can install and remove the drivers now
[17:08] <pitti> hmm
[17:08] <pitti> tseliot: so what was the issue you just had?
[17:08] <pitti> can you replicate the situation?
[17:09]  * tseliot tries again
[17:11] <tseliot> pitti: it works well now even if I launch it from the menu after killing the backend. Let me try it as I did before
[17:13] <tseliot> pitti: great, I can't reproduce the problem any longer :-)
[17:13] <pitti> tseliot: if you pull and debuild again, you can change the .service file to add --debug --logfile=/tmp/log.txt
[17:14] <pitti> tseliot: ah, neat; perhaps you previously had the intrepid package installed? last night's was faulty
[17:14] <pitti> tseliot: I just added --logfile to jockey-backend, so that you can run it auto-spawned with debugging
[17:15] <pitti> tseliot: (bug 251347)
[17:15] <tseliot> pitti: no, I hadn't installed Intrepid's package yet. I'll pull and debuild again
[17:15] <pitti> tseliot: well, no need to, unless you can reproduce the problem
[17:15] <pitti> tseliot: thanks for testing!
[17:17] <tseliot> pitti: ok. BTW it might be a good idea to add some auto-detection magic or to change the description of each driver flavour. This can be done later when the other parts of Jockey are complete.
[17:17] <tseliot> pitti: another thing: it doesn't tell me to restart my computer any more
[17:17] <pitti> BenC (CC: mdz): would there be a place in "the kernel crashdump scripts" at all which could call apport's script for turning a .vmcore into an apport report? or do we need to do that in an init script? in the latter case, I'd rather have it in apport's, instead of adding yet another init script
[17:18] <pitti> tseliot: restart> hm, bug; I'll have a look
[17:18] <pitti> tseliot: autodetect> you mean if you have several matching drivers?
[17:19] <tseliot> pitti: yes
[17:19] <pitti> yeah, I'd much prefer just showing one driver instead of three
[17:20] <tseliot> pitti: maybe you can show all the compatible drivers and highlight (in some way) the recommended driver
[17:20] <tseliot> pitti: maybe something done in the treeview with pango?
[17:21] <pitti> tseliot: how do you do that in envy?
[17:21] <BenC> pitti: what do you mean by "apport report"?
[17:22] <pitti> BenC: for bug 241322, mdz's comments
[17:22] <BenC> pitti: I could create such a file/report when creating the vmcore
[17:22] <BenC> no addition scripts needed
[17:22] <tseliot> pitti: I have 2 modes: Automatic installation and Manual installation. Automatic = the recommended driver is installed. Manual=the user will chose a specific flavour (since sometimes certain flavours work better with certain cards)
[17:23] <pitti> BenC: is that done at crash time? it'd involve a lot of python calls, etc., so it might not be appropriate when your kernel just crashed
[17:23] <BenC> pitti: no, it's done when the system is rebooted into the crashdump kernel...if I can write ~200Megs of vmcore, I think I can execute python :)
[17:24] <pitti> BenC: so would it be feasible to pipe the vmcore to /usr/share/apport/kernel_hook instead?
[17:24] <pitti> BenC: (or write it first, and then pass it as an argument to the script)
[17:24] <pitti> that might be more elegant
[17:25] <pitti> let's call it /usr/share/apport/kernel_crash, for the sake of not mixing up with package hooks
[17:28] <pitti> BenC: so all you'd have to do is <core dump write fd> | /usr/share/apport/kernel_crash
[17:28] <pitti> BenC: this would avoid having vmcore files laying around, and adding special cases to the init script
[17:28] <BenC> pitti: so if I pipe the vmcore to that script, it's all done?
[17:29] <pitti> BenC: yes; the script would read from stdin, compress it, add it as a field "VMCore", and collect additional data from the system (dmesg, hal, etc.)
[17:29]  * BenC wonders if 64M is enough memory to do that
[17:29] <pitti> BenC: and write it out to /var/crash/linux.crash
[17:30] <pitti> BenC: ah, you didn't mention that; it might be an issue, although I do pipelining carefully
[17:30] <pitti> I don't suck it in as a big block, but process it in 1 MB steps (similar to what the normal crash handler does
[17:30] <pitti> I have a test case which feeds (memory size) * 0.8 data to apport and watch memory usage
[17:31] <pitti> but it's python, so that could have it's own unpredictable memory requirements
[17:32] <pitti> BenC: so, in the end it might be better to just write it out as a file, and pick that up in the init script
[17:32] <emgent> evening
[17:33] <tseliot> emgent: hi
[17:33] <BenC> pitti: I'll give it a good testing
[17:33] <pitti> BenC: so what's your feeling, direct pipelining into python script, or pick it up in a full system at init time?
[17:35] <pitti> (while the amount of memory that apport needs doesn't scale with the size of the core dump/kernel dump you feed to it, I can't make assertions about how much it really needs)
[17:47]  * cjwatson looks at Anthony Baxter's "porting to python 3.0" presentation and watches python reinvent perlio
[17:47] <ScottK> cjwatson: Link please?
[17:48] <cjwatson> http://www.interlink.com.au/anthony/tech/talks/OSCON2008/porting3.pdf
[17:48] <ScottK> Thanks.
[17:49]  * ScottK sees slide 1 of 334 and chokes.
[17:53] <cjwatson> StevenK: it's in Anthony's super-brief presentation style
[17:54] <cjwatson> I mean, each slide has very little
[17:54] <cjwatson> makes for much more interesting presentations, though not as good to read afterwards
[17:54] <Keybuk> the man has the "next slide" button connected directly to his heartbeat
[17:55] <ScottK> It is readable and I'm enjoying it.
[17:55] <ScottK> Up to 79 already.
[17:58] <Keybuk> there's a Japanese presentation technique where you only show full-slide pictures
[17:58] <Keybuk> and you show each one for 20 seconds
[17:58] <Keybuk> and the presentation lasts a fixed time
[17:58] <Keybuk> or something
[18:17] <kelemengabor> hi mvo
[18:17] <kelemengabor> I got something for you :)
[18:17] <kelemengabor> http://delfin.unideb.hu/~kg0021/add-packagenames.diff
[18:17] <kelemengabor> the resulting pot looks like this: http://delfin.unideb.hu/~kg0021/packages.pot
[18:20] <mvo> kelemengabor: nice! I will get the diff now, but I can merge it only tomorrow I need to run now
[18:20] <slangasek> pitti: ask me about an upload of langpacks, that broke CD builds for pulling in a new package from universe :)
[18:20] <kelemengabor> mvo: ok, thanks
[18:20] <slangasek> TheMuso: not critical to include the pulse fix in alpha3, thanks, but I will want to errata it
[18:21] <kelemengabor> there is a small problem with the encoding, however
[18:21] <pitti> slangasek: uh, what, what? I only feel guilty about dropping all the aspell dicts from language-support, but that happened last week already
[18:21] <kelemengabor> but not our fault :)
[18:21] <pitti> slangasek: oh, hang on, openoffice-en-au?
[18:21] <pitti> myspell-en-au, rather?
[18:22] <slangasek> pitti: yes
[18:22] <pitti> argh, terribly sorry for that; it's in main now, anyway
[18:46] <surak> Wow, long time since the last time I was here!
[18:47] <surak> Here goes a simple one for the devs: /usr/include/c++/4.3/cstdlib:108: error: ‘::ldiv_t’ has not been declared
[18:48] <surak> I have this on dozens of functions (This is ibex, of course=
[18:49] <cjwatson> surak: have you read http://gcc.gnu.org/gcc-4.3/porting_to.html ?
[18:49] <surak> The list goest through half of the cstdlib : /usr/include/c++/4.3/cstdlib:113: error: ‘::atof’ has not been declared
[18:49] <cjwatson> also, nobody can help without a test program, but make sure you have followed the porting guide first
[18:50] <slangasek> pitti: yes, it's in main now; but since it wasn't coordinated, it broke a round of my livefs builds, and it looks like there are some packages on the alternate CDs that aren't installable without recourse to the network, as a result of that
[18:50] <surak> Hello Kamion, How are you?
[18:51] <cjwatson> if you intentionally use an old nick that my client no longer uses, it won't highlight
[18:51] <cjwatson> please don't :)
[18:51] <surak> oh, I'm sorry. Hello cjwatson, how are you? ;)
[18:51] <cjwatson> fine, thank you
[18:52] <surak> I'm with people from univ. of colorado & intel for this one, to make sure Pin, their dynamic instrumentation toolkit, works with Ibex.
[18:53]  * infinity misses Kamion and vorlon....
[18:53] <ion_> Who is vorlon now?
[18:54] <infinity> slangasek.
[18:54] <slangasek> infinity: join a Debian channel on OFTC, then? :)
[18:54] <infinity> slangasek: I'm in a few!  It's not the same. :P
[18:54] <slangasek> heh
[18:56] <mdz> pitti: ignore my nonsense comment on 251441; I thought it was the other bug about the script to create the crash report
[19:20] <slangasek> mdz: cjwatson tells me you're uploading dpkg for the liveCD installer crash; do you have an ETA?
[19:21] <cjwatson> slangasek: https://launchpad.net/ubuntu/+source/dpkg
[19:22] <slangasek> ... so ETA == end of publisher run, right
[19:23]  * slangasek thinks he needs to get himself a commandline tool on drescher that will answer that question properly and with ease :)st
[19:23] <cjwatson> reminiscent of antimony:~mdz/bin/awty
[19:24] <slangasek> heh
[19:28] <mdz> slangasek: was uploaded before you asked, should be in the queue now
[19:29] <slangasek> mdz: indeed, thanks
[20:56] <ScottK> slangasek: My condolences that you lost the minutes out of your life needed to write the why we freeze mail.  I'm actually shocked it was needed.
[20:57] <slangasek> ScottK: oh, well, I had nothing better to do besides watch paint dry^W^W dpkg progress through the publisher so I can build desktop ISOs
[20:58]  * ScottK looks around for a Main upload to do to keep slangasek's afternoon interesting.
[20:59] <mario_limonciell> ScottK, i say you add more dependencies to ubuntu-meta that are in universe
[20:59] <mario_limonciell> that will make slangasek excited
[21:00] <mario_limonciell> ;)
[21:00] <ScottK> Recommends are harder to troubleshoot.
[21:09] <pitti> mdz: you mean the bit that transforms  vmcore into an apport report? I'm not sure, I'd think it was easier to maintain/ship it in apport
[21:10] <mario_limonciell> pitti, oh i wanted to ask you about that jockey update that was going to introduce  the extra handler for hardy.  Did you and Tim get around to testing it?
[21:11] <pitti> mario_limonciell: no, I asked rtg and you for testing; I don't have the hardware
[21:12] <mario_limonciell> pitti, ah i had thought that rtg had actually gotten around to testing it, but i guess not then
[21:12] <mario_limonciell> pitti, where's the branch?  I'll track down some other hardware and see what i can do
[21:17] <mdz> pitti: yes
[21:30] <jordi> crimsun_: ping
[21:30] <jordi> crimsun_: I'm working on ALSA 1.0.17, and going over Ubuntu diffs
[21:31] <jordi> crimsun_: but there's so much, that I'd really like to see some more of this going in Debian directly rather than on patches.ubuntu.com
[21:31] <jordi> ie, what we talked prior to the hardy (or was it gutsy) release?
[21:32] <jordi> crimsun_: currently, pkg-alsa lacks manpower and we'd really be happy to see you join the team, that would make Debian's life easier and Ubuntu merges a lot less painful I suspect
[21:33] <jordi> doko: also, related to this, would you be available at some point to lend us a hand in the resolution of "#436201: libasound2-plugins: Could we get an ia32 package for amd64? "
[21:34] <jordi> doko it was filed ages ago, and iirc you did the biarch stuff in alsa-lib
[21:36] <jordi> TheMuso: ^ of course I'd be very happy if that could apply to you too :)
[21:36] <doko> jordi: ia32-* iz universe, hit, hint
[21:37] <doko> oops, s/hit/hint/ =)
[21:37] <jordi> doko: but you do have ia32-libs in main?
[21:38] <jordi> doko: last thing I know is the alsa plugins are in the ia32-libs and so on, which is *ugly*
[21:38] <doko> jordi: no, not anymore.
[21:38] <doko> at least not ia32-libs
[21:39] <jordi> ok
[21:40] <jordi> doko: anyway, if you're bored one day and want to have a look, I suspect it should be easy, once libasound2 was done
[21:40] <jordi> but biarch stff is like black magic to me
[21:40] <jordi> I remember looking at the alsa-lib patch you sent in and thinking "omg"
[21:41] <doko> these are the upstreams which are broken, and trying to define architecture specific stuff on their own
[21:42] <jordi> broken how?
[21:46] <doko> jordi: if the module paths are used/referenced outside /usr/lib, e.g. /usr/share or /etc, then something is wrong
[21:47] <jordi> doko: but are you talking about alsa-lib or alsa-plugins?
[21:47] <doko> you did want to do alsa-plugins ...
[21:47] <jordi> ie, do you know off-hand there was a problem with providing the 32 bit version of plugins cleanly?
[21:47] <jordi> right, right
[21:47] <doko> no, I didn't look
[21:47] <jordi> aaah
[21:48] <kirkland> doko: hi, lsb question for you.....
[21:49] <kirkland> doko: actually, usplash too
[21:49]  * doko quickly heads to bed ;)
[21:49] <jordi> doko: I guess we should try to come up with a patch based on your alsa-lib hackery, try if it actually works and seek your help if it doesn't
[21:49] <doko> jordi: sure
[21:49] <kirkland> doko: http://pastebin.ubuntu.com/30089/
[21:49] <jordi> post-lenny I'm afraid
[21:50] <kirkland> doko: i'm about to open a bug, and post a debdiff with that change....
[21:50] <kirkland> doko: the current "type" test will check if usplash_write exists
[21:50] <kirkland> doko: but it ignores whether or not a user has permission to send messages to the usplash daemon
[21:51] <doko> hmm, and it should fail, if usplash_write doesn't exist?
[21:51] <kirkland> doko: right
[21:51] <kirkland> doko: my change will preserve that
[21:51] <doko> really?
[21:52] <kirkland> well, if it's not in the path, anyway
[21:52] <kirkland> hmm, well, there's a difference in exit code, 127 vs. 1
[21:52] <doko> better ask a usplash/boot maintainer
[21:52] <kirkland> doko: okay
[21:53] <kirkland> doko: is that cjwatson, evand?
[21:58] <evand> Is there a usplash maintainer?
[21:58] <evand> I didn't think there was.
[21:59] <kirkland> evand: can you recommend someone who knows a bit more about it than I?
[22:01] <infinity> tjaalton: Ping?
[22:02] <infinity> tjaalton: The --enable-glx-tls change in xorg-server appears to have royally broken xvfb.
[22:05] <doko> infinity: ohh, verified this?
[22:05] <infinity> doko: That seems to be what it's choking on.  Without that flag, it doesn't go hunting for dri libs (which fail to load for xvfb...)
[22:05] <doko> infinity: hardy as well?
[22:06] <infinity> doko: No, this was an intrepid change.
[22:06] <evand> kirkland: I'm not quite sure, I believe mjg59 used to handle bugs on it, but I have no idea who does now.
[22:06] <infinity> xorg-server (2:1.4.99.905-0ubuntu2) intrepid; urgency=low
[22:06] <infinity>  -- Timo Aaltonen < tepsipakki@ubuntu.com>   Mon, 07 Jul 2008 11:44:39 +0300
[22:06] <kirkland> evand: true, i saw his name through the source code
[22:06] <infinity> That's when it should have broken, if I'm right...
[22:06] <doko> bryce, bryce_: ^^^
[22:07] <doko> hmm, now running intrepid on an intrepid kernel, the mauve tests do work
[22:08] <infinity> Yeah, I'm on a hardy kernel here.
[22:08] <cjwatson> kirkland: I don't see how that will have any useful effect. usplash_write.c main() starts:
[22:08] <cjwatson>         if (argc < 2) {
[22:08] <cjwatson>                 fprintf(stderr, "Usage: usplash_write COMMAND...\n");
[22:08] <cjwatson>                 exit(1);
[22:08] <soren> infinity: You wouldn't happen to have a deb compiled without that flag, would you?
[22:08] <cjwatson>         }
[22:08] <cjwatson> kirkland: so usplash_write with no arguments will always exit 1
[22:08] <kirkland> cjwatson: hmm, okay, so here was my test case....
[22:09] <cjwatson> kirkland: you could just check uid == 0 ;-)
[22:09] <infinity> soren: You could grab 2:1.4.99.905-0ubuntu1 from launchpad, or I could build a new one...
[22:09] <cjwatson> :q
[22:09] <cjwatson> (sorry)
[22:09] <soren> infinity: xserver-xorg-core, is it?
[22:09] <kirkland> cjwatson: dustin@ubuntu:~$ sh /etc/init.d/ssh status
[22:09] <kirkland> open: Permission denied
[22:09] <kirkland>  * sshd is running.
[22:09] <cjwatson> kirkland: any argument you might pass would actually get written to the usplash fifo; if you want to do this, you'll have to add an option to usplash_write to support it
[22:09] <kirkland> cjwatson: (non root user checking status)
[22:09] <ion_> :%norm A (meh)
[22:10] <cjwatson> kirkland: sure, I understood the use case perfectly already, your code is just wrong ;-)
[22:10] <infinity> soren: xvfb in my case.
[22:10] <infinity> soren: But if it has to do with kernel dri/drm interfaces, any xserver would have the same problem, I suppose.
[22:10] <kirkland> cjwatson: ah, good point ;-)
[22:11] <kirkland> cjwatson: usage statement, even as root :-P
[22:11] <cjwatson> kirkland: (it might have worked for you in testing, and it would certainly suppress that error, but only because it will prevent lsb-base-logging from ever writing to usplash)
[22:11] <soren> infinity: Right. I'm just experiencing a bug that I can find the cause of, so I'm willing to try anything.
[22:11] <kirkland> cjwatson: yup, i didn't test with root priv's, i see that now
[22:11] <kirkland> cjwatson: okay, so seriously checking UID would be sufficient, you think?
[22:11] <infinity> soren: Do you have an strace of the bug in question?
[22:12] <soren> infinity: No, it hangs the machine.
[22:12] <infinity> soren: Oh.  Probably a different bug, then. :)
[22:12] <soren> infinity: Probably. Couldn't hurt to try, though. The very last thing I manage to see before it dies is something about going to look for DRI modules or whatnot.
[22:13] <cjwatson> kirkland: I wouldn't lose any sleep over that approach, certainly, though it doesn't check whether usplash is running
[22:14] <cjwatson> kirkland: I'd be cautious of anything that does very much more work, though, as it would slow down the whole boot sequence
[22:14] <kirkland> cjwatson: looks like we need a usplash status action :-)
[22:14] <kirkland> cjwatson: i'll add the uid check for now
[22:14] <kirkland> cjwatson: that'll be quick
[22:14] <cjwatson> it'll have to fork id for every init script
[22:15] <cjwatson> the alternative would be to silently ignore EACCES in usplash_write
[22:19] <kirkland> cjwatson: that would certainly be the most performant solution
[22:19] <kirkland> cjwatson: one minute, let me test a patch to usplash.....
[22:20] <cjwatson> a little bit evil, but then who uses usplash in other contexts anyway? :)
[22:21] <infinity> I win!
[22:21] <infinity> doko: For now, this works for me 'xvfb-run -s "-extension GLX" --listen-tcp --server-num=7 /usr/bin/make -k jtregcheck
[22:21] <infinity> doko: Obviously still a bug somewhere, but if you run xvfb GLX disabled, as above, it works.
[22:21]  * cjwatson -> bed, night
[22:22] <cjwatson> kirkland: needs a big honkin' comment if you do take that approach, mind :)
[22:22] <doko> ahh, will use that for the next upload
[22:22] <kirkland> cjwatson: ;-)  righto
[22:22] <kirkland> cjwatson: i see usplash is another one maintained in bzr
[22:23] <kirkland> cjwatson: perhaps tomorrow, i need a run down on how my patch/bug/test workflow changes for bzr projects
[22:23] <kirkland> cjwatson: i was quite confused by the differences you suggested to me for the grub merge
[22:23] <infinity> doko: I might leave it to you to file the bug... I'm unsure on the "correct" fix... One half of me thinks it shouldn't break at all, the other half of me says "meh, the only thing xvfb is realistically used for is headless testsuites, maybe xvfb-run should just be told to disable GLX by default".
[22:23] <jordi> can anyone enlighten me on the lpia arch?
[22:23] <jordi> I'm adding lpia to all Debian ALSA packages
[22:24] <jordi> but I see some alsa packages in ubuntu don't do this
[22:24] <jordi> in short, should alsa-tools support LPIA?
[22:24] <doko> infinity: on the other hand this might break python-glx (or something like that) builds
[22:25] <infinity> doko: I suppose it's possible that something, somewhere, might have a GLX testsuite... If so, then this bug needs to be resolved.
[22:25] <infinity> doko: Frankly, an Xserver that doesn't run on the previous release's kernel is a bit scary anyway, IMO.
[22:25] <infinity> doko: If that is, indeed, the issue.
[22:25] <infinity> doko: Makes for an upgrade nightmare, if users get X upgraded, and then the new kernel bombs, etc.
[22:36] <crimsun_> jordi: yes, alsa-tools should.
[22:37] <crimsun_> jordi: and, I'm traveling quite a bit, so I'm unsure how frequently I can contribute.  I'm already doing a lot of BTS work where I can.
[22:37] <jordi> crimsun_: I saw
[22:37] <jordi> crimsun_: I'd like to make the ubuntu diff a lot smaller
[22:38] <infinity> jordi: Oh, sorry, missed the question.  In general, anything that can support lpia (which, at the toolchain level, is just a differently-optimised i686) should do so, pretty please.
[22:39] <ion_> benc: Any guesses on the release of the next kernel image? I’m not really in any hurry, but would just like to get to test the fixed compcache module.
[22:39] <jordi> infinity, crimsun_: okay, new alsa packages will have it
[22:39] <jordi> today's alsa-lib upload is the first one
[22:41] <infinity> doko: Wow, that's a long testsuite...
[22:41] <doko> takes 3-4h
[22:43] <infinity> doko: I'm seeing that...
[22:43] <infinity> doko: Oh well... I'm satisfied that it's working, I'll just Ctrl-C it. :)
[22:47] <BenC> ion_: hopefully tomorrow
[22:47] <ion_> benc: Alright, cool.
[23:03] <tjaalton> infinity: so you've tried it without that option?
[23:05] <infinity> tjaalton: No, it was some creative googling of errors in strace that led me to believe that's what broke it.
[23:06] <infinity> tjaalton: For starters, it looks for dri libs (and xvfb doesn't depend on libgl1-mesa-dri), and once that's installed, it can't dlopen it due to unresolved symbols...
[23:06] <tjaalton> infinity: oh, ok
[23:06] <tjaalton> it probably tries to load swrast_dri
[23:06] <tjaalton> or what was it called, can't check now
[23:07] <infinity> 12:25 < infinity> [pid  5961] write(2, "(EE) AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so
[23:07] <infinity>                   failed (/usr/lib/dri/sw
[23:07] <infinity> 12:25 < infinity> rast_dri.so: undefined symbol: _glapi_tls_Context)\n", 129) = 129
[23:07] <infinity> 12:25 < infinity> [pid  5961] write(2, "\nFatal server error:\n", 21) = 21
[23:07] <infinity> Yeah, it does.  And when it's actually there, the above happens.
[23:07] <tjaalton> sounds like a bug then ;)
[23:08] <infinity> According to doko, it works on an intrepid kernel, so I suspect some drm ABI breakage.
[23:08] <infinity> Which would be a bit problematic for the real xserver too, on aborted/incomplete upgrades.
[23:09] <tjaalton> that should be easily tested
[23:32] <mpt> persia, my sound has gone again after resuming from hibernate
[23:33] <mpt> (sorry, didn't realize until just now)
[23:41] <mathiaz> kees: jdstrand: what are the valid caracters than you can find in crypt string ?
[23:42] <mathiaz> kees: jdstrand: can you the ' and " in a crypt string ?
[23:42] <mathiaz> kees: jdstrand: can you *have*
[23:46] <crimsun_> mpt: which driver?  (cat /proc/asound/modules)
[23:47] <mpt> crimsun_,  0 snd_intel8x0
[23:47] <crimsun_> mpt: do you have a bug report I can look over?
[23:48] <mpt> crimsun_, bug 80344
[23:48] <jdstrand> mathiaz: crypt as in crypt()-- man crypt says the glibc2 version uses [a–zA–Z0–9./]
[23:49] <mathiaz> jdstrand: hm - thanks :)
[23:49] <crimsun_> ah, -that- bug.
[23:53] <mpt> yeah, that bug :-/
[23:59] <crimsun_> mpt: amixer get 'Master Mono'|grep 'Playback.*%'