[01:06] pitti: eep do we have a regression of bug 95368 on our hands? [01:06] Launchpad bug 95368 in hal ""Cannot remove directory" on unmount due to stale .hal-mtab entries" [High,In progress] https://launchpad.net/bugs/95368 [01:06] seems like 4 users have reported it on Intrepid [01:13] .c [01:14] Password: [01:15] heh [01:44] TheMuso: I guess that means you think that yes, we should fix it for intrepid? :) [01:53] slangasek: Yes, I'm going to look into it today. [01:53] ok [01:53] how is bug #274124 coming along? [01:53] Launchpad bug 274124 in pulseaudio "Race condition in pulseaudio loading for GNOME session" [High,Confirmed] https://launchpad.net/bugs/274124 [01:53] will we get an upload today? [02:07] slangasek: Just have to slap the solution into the package. On my agenda also. [02:32] superm1: Would you please look at the last comment in Bug 207473 and see if there's anything Dell specific that could be at issue. [02:32] Launchpad bug 207473 in hal "Screen brightness double level changes" [Medium,Confirmed] https://launchpad.net/bugs/207473 [02:33] slangasek: Would you please accept milter-greylist? === jamesh__ is now known as jamesh [03:15] ScottK: done [03:16] slangasek: Thanks. That's the libspf2 transition we discussed at the last release meeting done then. [03:16] yep \o/ [03:21] setting up Gutsy VM's really takes you back.... [03:22] it's amazing how much we've progressed in just a few release cycles. [04:17] slangasek: sorry i thought we were supposed to get special approval for any upload during final freeze [04:22] slangasek: Just uploaded the pulseaudio race condition work-around. [04:26] TheMuso, Should that cover device recognition as well, or just desktop sounds? [04:26] persia: just the desktop login sound race condition. [04:26] OK. I'll file a bug then. Thanks. [04:27] persia: Whats the problem? [04:28] TheMuso,: I rebooted with a USB interface connected, and only the USB interface shows in pavucontrol : the onboard is missing for output (but is present for input). [04:28] persia: That could be the race in effect there. [04:29] i.e canberra-gtk-play has the onboard card, so pulse can't grab it. [04:29] That's what I was thinking. I'll retest with the new one before I file the bug then. [04:29] persia: What session manager is this with? gnome-session, or something for mobile? [04:29] gnome-session : this is my primary laptop. [04:29] Ok then. [04:30] I think -mobile uses gnome-session as well, and -mid doesn't use pulse. [04:30] Right. [04:30] * persia 's -mobile HW is currently on loan [04:30] * TheMuso nods. [04:31] TheMuso, Just as a counter-case, as long as I don't attach the USB device until my session is live, this doesn't happen, so it's not a core problem, and easily worked around for release. [04:31] persia: Right. [04:41] linux-rt and friends uploaded. [04:42] slangasek: I've packaged and tested the clamav RC. See Bug #286176. The debdiff is painful and makes it look worse than it is. I had to add one line to the freshclam postinst after I made the debdiff. [04:42] Launchpad bug 286176 in clamav "FFe Request for Clamav 0.94.1 RC" [Undecided,New] https://launchpad.net/bugs/286176 [04:42] slangasek: What else would you like to see in the FFe? [04:55] slangasek: I went ahead and uploaded it so you can review/accept/reject from the queue [05:02] calc: all uploads during final freeze have to be approved by the release team; that doesn't mean the approval has to happen /before/ you upload, because they'll be held in the queue anyway :) [05:04] TheMuso: thanks, will review :) [05:04] ScottK: right, I'll have a look shortly [05:18] slangasek: I'm heading to bed, so I guess I'll find out what you decided in the morning. [05:49] persia: I'm a bit confused by the linux-rt upload; the changelog seems to bear no relation to the previous version? [05:49] seems to have motu-release ack though, so approving (and closing bug #281276 by hand) [05:49] Launchpad bug 281276 in linux-rt "Upgrade linux-rt to 2.6.27" [Undecided,Confirmed] https://launchpad.net/bugs/281276 [05:49] slangasek, From what I understand, it was completely rebased on the new kernel, and the previous source was not used in it's construction. [05:49] hum, ok [05:50] With luck, we'll be able to come up with some sane way for the packages to interact in jaunty : the kernel team has been very busy with preparing both 2.6.26 and 2.6.27 this cycle. [05:51] btw, it appears that bug #229499 remains unfixed in this upload [05:51] Launchpad bug 229499 in linux "Latency regression with real time kernel and dynamic ticks feature" [Undecided,Fix released] https://launchpad.net/bugs/229499 [05:51] (the only linux-rt bug that was targeted to intrepid) [05:52] Bother. Thanks for pointing that out. [05:57] slangasek: I've just uploaded linux-lpia-meta, if you'd like to cast your eyes over it === viviersf{weekend is now known as viviersf [06:34] StevenK: accepted, thanks [06:42] slangasek: Thanks! === tkamppeter_ is now known as tkamppeter [07:05] Good morning [07:05] * wgrant escapes quickly. [07:05] hi pitti [07:06] * Hobbsee throws pitti a gummybear, and a bit of chocolate cake [07:06] TheMuso: festival has already been in main, so I just adjusted recommends, not demoted festival; likewise, flite is already in main (the library only), I guess it's a build dep [07:06] pitti: right. [07:07] jdong: it has never really been fixed [07:13] good morning [07:14] morning dholbach [07:14] hi Hobbsee [07:20] directhex, ping [07:22] pitti, I have fixed an important bug in the CUPS package (bug 286048) on the Debian BZR. [07:22] Launchpad bug 286048 in cups "RELEASE FREEZE EXCEPTION: When requesting n copies, n*n or even n*n*n copies get printed" [Critical,Fix committed] https://launchpad.net/bugs/286048 [07:22] tkamppeter: saw your mail; I'm currently building the package [07:22] NCommander, be quick, i need to go to work in 8 minutes [07:22] directhex, how's hardware support on ia64 [07:23] directhex, I'm rebasing the -ports kernel to 2.6.27, and it seems whoever did the ia64 kernel press and held enter during make config, so most of the drivers are compiled out unless I'm loosing my mind [07:23] pitti, did the release team already accept it? [07:23] NCommander, AFAIK pretty good (i run SLE on the kit at work) [07:23] directhex, will you be willing to smoke test the ia64 kernel once I finish rebasing? [07:23] tkamppeter: I need to upload it first :) and yes, I'll accept it afterwards (it is your upload, I'm just sponsoring) [07:24] NCommander, i doubt i'd be able to i'm afraid, it's production kit [07:24] know where I can find someone with some spare ia64 hardware? [07:27] pitti, are you in the release team? [07:27] tkamppeter: yes [07:28] pitti, I have some other bugs where I am not sure whether we should make a freeze exception: [07:28] tkamppeter: if the fixes are obvious and easy, and you have packages prepared, please upload them [07:28] pitti: bug #284444 [07:28] Launchpad bug 284444 in system-config-printer "Printer Configuration Program Crashed" [Medium,Triaged] https://launchpad.net/bugs/284444 [07:28] tkamppeter: at this point, we can accept those until this afternoon, but they must *really* be safe [07:36] pitti, the s-c-p fix is uploaded. [07:41] pitti, after uploading I get [07:41] Rejected: [07:41] Signer is not permitted to upload to the component 'main' of file 'system-config-printer_1.0.5+git20080819-0ubuntu6.dsc'. [07:41] tkamppeter: oh, someone needs to extend your upload ACL for that; mdz, whom to ping for that? [07:42] It is strange for me. The message which one usually gets on an after-freeze upload is different. [07:42] tkamppeter: yes, I think your upload ACLs were put in place recently, and they forgot s-c-p [07:43] mdz has removed my general core-dev right, probably he assumed that my ACL is in place, but probably no one touched it. [07:44] mdz, can you set the upload ACLs in Launchpad? Or did you do it already? Has Launchpad perhaps a bug? [07:49] pitti, I can send you the two packages, so that you can upload them, as I do not know until when my upload gets fixed. [07:49] tkamppeter: ok [07:57] oh, happy Feisty EOL day! [07:58] kees, jdstrand: ^ happy? :) [07:58] pitti, the packages are now on http://www.linuxfoundation.org/~till/tmp/ubuntu/intrepid/fe/ [07:59] It is all tested, the packages actually fix the reported bugs and Ghostscript two PDF-workflow-related upstream bugs in addition. [08:00] On Ghostscript I have mass-tested all built-in drivers with a script which creates a queue for every driver, passes a job through it, and then checks for errors and a reasonable output size. [08:01] * fabbione hugs pitti [08:01] * pitti hugs fabbione back; Padre! [08:07] ScottK, it's actually a kernel bug [08:07] ScottK, caused by the way the BIOS allows for multiple different video cards [08:07] ScottK, more or less bug 226981 [08:07] Launchpad bug 226981 in linux "Hardy: FN-up/down keys change brightness too rapidly on DELL XPS m1330" [Low,Confirmed] https://launchpad.net/bugs/226981 [08:09] ScottK, i'll add the upstream kernel.org bug tracker for the bug === MacSlow_ is now known as MacSlow [08:17] ScottK, that and at least one of those bugs is mis appropriately marked as a duplicate. if there are *any* hangs associated with it, it's a kernel bug about key releases; bug 261721 [08:17] Launchpad bug 261721 in linux "X never sees brightness key release events" [High,Triaged] https://launchpad.net/bugs/261721 [08:25] hey DktrKranz [08:27] hi NCommander [08:27] DktrKranz, I verified the GNAT packages work :-) [08:28] we've finished! \o/ [08:28] yes, I noticed, thanks ;) [08:28] SO now what happens? [08:28] (I assume you need to get the archive admins to push to -updates, right? [08:28] martin already copied to updates [08:28] WOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO [08:29] i wonder if i could convince the powers that be on the ubuntu forums to add "--prefix=/usr " to the swear filter [08:29] :-) [08:30] ah, it feels good to finally finish that gnat transition [08:31] sure. I'll adjust the spec accordingly soon [08:31] and eventually track for regressions/pending issues, just to make sure we have really finished [08:31] Probably the first/only transition to be done entirely through -updates ;-) [08:31] DktrKranz, the packages weren't installable. Anything at this point is an improvement [08:32] I hope to avoid those in the future [08:32] We have to make sure our version of gnat stays in sync with Debian [08:33] gnat-4.2 is no longer here [08:33] and I hope 4.1 will go away soon [08:33] We can NBS it out on Jaunty [08:34] it won't be that difficult [08:34] * NCommander just needs his MOTUship ;-) [08:34] go for it, then ;) [08:35] I don't think you mean NBS [08:35] er [08:35] Just removing the rdepends and getting rid of it [08:35] * NCommander drinks his coffee [08:36] why are you drinking coffee at 3am? [08:36] let's think of it for jaunty, maybe together with debian maint [08:36] slangasek, cause I woke up at 12:00 [08:37] NCommander: broken timezone! [08:37] * slangasek scratches his head [08:38] mvo: MacSlow: new libgksu works great [08:38] amitk, sweet news ... thanks for the feedback! [08:39] slangasek: thanks for noticing my bad upload, I was definitely under crack :) [08:39] cool, thanks amitk! [08:39] amitk & seb128 I have a sleep disorder [08:39] 48 hour days? [08:40] DktrKranz: that's what I'm here for... :) [08:40] hehe [08:40] NCommander: you don't think drinking coffee at 3am is a cause of disorder? [08:40] pitti, when you approve Ghostscript, then take also the new foomatic-db which I have put onto the same URL now. This foomatic-db has a workaround for a bug in Ghostscript removed. [08:40] NCommander: stop working so much and go to bed ;-) [08:40] seb128, I woke up after 12 hours of sleep at 0:00 [08:41] pitti, the removal of the workaround is also covered by the Ghostscript mass testing which I did. [08:41] tkamppeter: gs and scp are done [08:41] mvo, can I mark LP #275172 fixed then? [08:41] hey pitti! [08:41] Launchpad bug 275172 in gksu "libgksuui crashes on statup in the blur code on some systems" [Medium,In progress] https://launchpad.net/bugs/275172 [08:41] tkamppeter: does the workaround hurt for anythuing? [08:41] * pitti hugs seb128, bonjour [08:41] * seb128 hugs pitti [08:42] pitti: how are you? [08:42] pitti, the approval message of gs appeared some seconds ago. [08:42] mvo, or do we need more positive feedback about the crasher being fixed? [08:42] seb128: quite okay, and you? [08:42] pitti: good, I got over my cold and slept enough during the weekend, ready for a GNOME marathon today ;-) [08:42] MacSlow: I think its fine to close it now we got positivie feedback and no negative [08:43] so who here is good at debugging threading race conditions? [08:43] MacSlow: feel free to add "please reopen if you still experience this problem" or something like that [08:43] pitti, so can you approve foomatic-db, too? It only removes the workaround for a bug which is now fixed in gs (bjc600/bjc800). [08:43] * NCommander runs really fast from slangasek [08:43] tkamppeter: you can't upload that either? [08:44] slangasek, what has race conditions? [08:44] NCommander: libgstpulse or libpulse [08:44] Deadlock? [08:44] pitti, I will try. Perhaps in the ACL only somne packages were forgotten. [08:44] segfault on shutdown (and possibly at other times) [08:44] * NCommander winces [08:44] That sounds evil to fix [08:45] well if it was trivial I wouldn't be trawling for people good at thread debugging. :) [08:47] slangasek, is there an upstream bug? [08:47] I have no idea === hunger_t is now known as hunger [08:49] pitti, mind copying ocamlsdl (bug 249355) to hardy-updates? It doesn't show up in pending-sru page, but it has been verified long ago. [08:49] Launchpad bug 249355 in ocamlsdl "ocamlsdl and lablgl conflict over Raw" [Undecided,Fix committed] https://launchpad.net/bugs/249355 [08:53] DktrKranz: thanks, done [08:53] * DktrKranz hugs pitti [08:53] * pitti hugs back DktrKranz [09:02] mvo, should I also close all the duplicates on LP #275172 ? [09:02] Launchpad bug 275172 in gksu "libgksuui crashes on statup in the blur code on some systems" [Medium,In progress] https://launchpad.net/bugs/275172 [09:02] pitti, I also cannot upload foomatic-db. Seems that the new Launchpad with ACLs is not yet installed. [09:02] bah [09:02] mvo, or link to the comment thread of it pointing out we've a fix in place? [09:02] MacSlow: just mark them as duplicates of the fixed one [09:02] tkamppeter: does the workaround actually hurt anything? [09:03] MacSlow: thanks for cleaning that up! [09:04] pitti, the workaround only leads to more PDF->PS and back conversions, slowing down the printing and the probability of a bug is higher than when the PDF is passing through straight to the printer driver. [09:05] The patch is very small and only affects the Ghostscript command lines for the two bjc600 and bjc800 drivers, nothing else in the Foomatic dataabse is changed. [09:05] ok [09:06] whoops pitti, when you took discover1 out on friday, it broke mythbuntu live disk builds. can you or whomever is manning the approval queue today let mythbuntu-meta 0.30 through to allow the dailies to get building again? [09:07] superm1: uh, sorry; I checked reverse dependencies, and there was nothing left [09:07] that's odd. it was a recommends for mythbuntu-live [09:07] mvo, hm... the dups don't let me add a comment ... well then they point to #275172 anyway so people should find it anyway. [09:08] hey njpatel, sabdfl [09:08] er by 0.30, i meant 0.31. I think 0.30 was in the archive already [09:08] superm1: FAILED: mythbuntu-meta (The source mythbuntu-meta - 0.30 is already accepted in ubuntu/intrepid [09:08] hey hey MacSlow [09:08] superm1: oh, checkrdepends doesn't check recommends, that'd be it [09:08] pitti, yeah i just saw i uploaded the 0.30 again by accident. 0.311 should show up now [09:09] tkamppeter: okay, uploaded === Tonio___ is now known as Tonio_ [09:37] superm1, pitti: mythbuntu-meta accepted [09:40] slangasek: bah, I get permission errors on the queue page again; I accepted some xfce package, but the other brings an error [09:40] slangasek: does that happen for you as well? [09:41] I don't use the web interface except for testing :/ [09:44] superm1: hmm, ok, xorg-driver-fglrx (containing libAMDXvBA.so.1.0, bug #271794) is in multiverse, not restricted... has somebody demoted it as part of component-mismatch cleanup since you filed that bug? [09:44] Launchpad bug 271794 in fglrx-installer "Re-promote gcc-3.3 to main" [Undecided,Fix released] https://launchpad.net/bugs/271794 === mdz_ is now known as mdz [09:46] anyone know where to find the file: libopenal.so.0 ? [09:47] jussi01: libopenal0a: /usr/lib/libopenal.so.0 [09:47] jussi01: apt-file is your friend. [09:48] Mithrandir: yeah, I tried it, obviously wrongly as it returned nothing... [09:48] jussi@Galaxy:~$ apt-file search libopenal.so.0 [09:48] jussi@Galaxy:~$ [09:48] Mithrandir: thanks though :) [09:49] tkamppeter: the LP database certainly *thinks* you're allowed to upload system-config-printer [09:49] tkamppeter: http://paste.ubuntu.com/60035/ [09:50] tkamppeter: looks like an LP bug, unless the ACLs were changed between that upload being rejected and me looking at them [09:51] (that's output from './edit_acl.py -p till-kamppeter query' in lp:~kamion/+junk/ubuntu-archive-tools) [09:53] jussi01: That's an old and apparently horribly library. Feel free to poke upstream into linking against libopenal.so.1 [09:53] s/y l/y buggy l/ [09:57] jussi01, There was a transition to make that go away in intrepid. Did something get missed? [09:58] RAOF, Well, it's mostly only horribly buggy if you don't have a creative card, although it's still buggy if you do (just not horrible). [09:58] persia: Heh. [09:59] mdz: Do you think the iwl3945 issue is fixed by disabling ftrace? [10:00] I thought it would only affect module removals [10:00] cjwatson, I got a mail from mdz that he has fixed (upodated) my ACL. [10:01] lool: there were several independent reports that the problem did not recur with -7.12 [10:01] lool: can you reproduce it? [10:02] I will try to do some reboots; I couldn't get the hang reliably before though [10:02] cjwatson: the ACLs were changed between that upload being rejected and you looking at them (by me) [10:02] Will confirm in the bug [10:03] persia: in intrepid it seems to be known as libopenal1 [10:03] jussi01: Right, it broke ABI fairly recently. [10:04] mdz: Eh just got your comment in the bug report [10:04] jussi01, That's an entirely different piece of software : openal-soft vs. openal. The new one is based on a community fork of some code creative released open-source. [10:04] persia: ahh... [10:11] cjwatson, mdz, I have done a test upload now and it works. The package waits for FE approval now. Please reject it. And thank you for the quick fix. [10:12] tkamppeter: good, thank you [10:12] slangasek, pitti : I have done the fix for nautilus-share, see bug #212098 [10:12] Launchpad bug 212098 in nautilus-share ""easy" file sharing not notifying about logout/login" [High,Confirmed] https://launchpad.net/bugs/212098 [10:15] cjwatson: is it possible yet for uploads which originally target intrepid to be redirected to jaunty when it's open, or do they still need to be re-uploaded? [10:15] pitti: any chance that you could look at that one? [10:16] tkamppeter: that's the system-config-printer upload that you're saying should be rejected? [10:16] slangasek, yes, the 0ubuntu7. [10:17] Pitti, has sponsored my upload of the 0ubuntu6 which contains an actual bug fix and so I did not have anything left to upload for testing. So I have created an unchanged 0ubuntu7 only for testing. [10:17] ok, rejected [10:17] slangasek,cjwatson: to ask the real question, I have changes which are ready for upload but which aren't appropriate for 8.10. what should I do with them? [10:18] james_w: perhaps there's a branch where I could commit them? ;-) === seb128_ is now known as seb128 [10:18] I like that as an answer... :) [10:18] mdz: hopefully shortly [10:19] james_w: this is alsa-driver fwiw [10:21] Ubuntu got article of the day on German Wikipedia: http://de.wikipedia.org/wiki/Wikipedia:Hauptseite [10:34] pitti: do you have a rule of thumb for when apport package hooks should go in apport itself vs. in the package? [10:43] mdz: hm, hard to put into words; usually I prefer "in the package", but for things like the kernel it's both easier and less conflict-ful (several versions in parallel, etc.) to ship it in apport [10:43] slangasek: 212098> yep, will do [10:46] pitti: I've written one for alsa-base which I'm inclined to put into the package [10:47] mdz: another thing is, if it would be the only package delta, I'd also be inclined to put it into apport instead [10:48] mdz: but we have a delta anyway, so I agree, putting it into alsa-base is more appropriate [10:48] pitti: it will use the upstream alsa-info.sh script, which is currently not installed, so it needs to be modified to install the script anyway [10:49] pitti: however, once it's there, I expect that e.g. pulseaudio will want this info as well, which makes me wonder whether it should go in apport.hookutils [10:49] pitti: or if hooks should invoke other packages' hooks [10:50] mdz: if there's any doubt, I don't mind at all to put it into apport for now; it's arch:all and builds quickly, so not disruptive to the RC [10:50] mdz: (OTOH we'll disable apport for the final release anyway) [10:51] ok, need to rush to the post office before they close; bbl [10:51] pitti: I was planning to hold these changes until post-8.10 anyway [10:52] ah, ok :) [10:52] pitti: though, if you will upload apport anyway for some reason, then please do merge my hookutils branch [10:53] mdz: the only upload I planned so far is to disable it; but I can merge it in trunk, sure [10:56] if I see a pointer with the value 0x10 in a stacktrace, is that usually indicative of a particular problem? [11:00] james_w: uninitialized pointer is my first guess [11:01] second guess is "somebody took an offset from NULL" [11:01] james_w: if you can trust the value it's showing you (watch out for debugger unreliability, compiler optimization, etc.), then that pointer is likely invalid === asac_ is now known as asac [11:01] james_w: my first guess would be "int value assigned to a pointer" [11:01] james_w: URL for the stacktrace? [11:01] james_w, If you are looking at a member of a structure, the pointer to the structure is probably null. [11:01] I believe threads may be involved, but from what I can see the pointer is assigned NULL, and then next shows up with 0x10 [11:02] it's only in gdb currently, I'll extract it to a file [11:04] james_w: sounds like the debugger is lying to you [11:04] it unfortunately does that a lot [11:04] damn [11:04] james_w: add a printf to dump the value of the pointer at the same spot and see what that says [11:06] * wgrant recommends the use of -O0, too. [11:06] wgrant: indeed [11:06] That can make gdb much less useless. [11:10] hmm, apparently valid pointer that time, but still SIGSEGV [11:11] Valid meaning it points to something, or just doesn't look so bogus at a glance? [11:11] james_w: try using valgrind [11:11] ah, no, it's invalid, just not as obviously as invalid as 0x10 [11:11] valgrind is good until it starts segfaulting. [11:11] james_w: valgrind often gives you good clues [11:12] wgrant: it doesn't segfault often for me [11:12] james_w: so the reason you're looking at this pointer is that it's the cause of the SEGV? [11:12] seb128: Neither, but I've encountered a couple of particularly nasty situations where it does. [11:12] (did you post a url to the stack trace that I missed somehow?) [11:12] seb128, my evo is acting up recently ... since a week or so it forgets its password ver often (i never had to type it in in hardy or before), if i get up in the morning i get recieveerrors and have to rstart it to even get my first chunk of mail [11:13] *restart [11:13] wgrant: valgrind and gdb both beat analyzing core dumps by hand, so... [11:13] slangasek: This is true. [11:13] http://paste.ubuntu.com/60057/ [11:15] james_w: and 'list' is the pointer that was showing as 0x10 before? [11:15] yup [11:15] I'm pretty sure at least, it was yesterday [11:15] and this latest stack trace is after rebuilding with -O0? [11:15] no, I haven't rebuilt, I'll try that now [11:17] but I appear to have turned this crash from a race condition to a consistent crash every time, I don't know if that is good or bad [11:17] good :) [11:18] also, is there a way from a glib program to get a thread id for the thread the code is executing in? [11:18] I wonder if I misunderstood which thread was which here [11:19] I'm not sure any thread ID you would get from inside glib would usefully correlate to how gdb identifies your threads [11:21] definitely needs a rebuild with -O0, the line number in the backtrace doesn't match the function name [11:21] this is a patched consolekit [11:21] bug 269651 [11:22] Launchpad bug 269651 in consolekit "console-kit-daemon crashed with SIGSEGV in g_str_hash()" [High,In progress] https://launchpad.net/bugs/269651 [11:26] james_w: http://launchpadlibrarian.net/18690266/consolekit_0.2.10-1ubuntu9.diff, then? [11:33] james_w: hrm, does this happen to be on amd64? [11:35] james_w: I ask because of the use of GUINT_TO_POINTER(), which certainly *sounds* suspect, but I can't find a definition of it anywhere in libglib2.0-dev... [11:37] OTOH, it's plausible the indices really are integers in this case [11:38] pitti, Would you have time for some questions about HAL? I want to export an input.joystick property for joysticks so evdev will be able to not grab them, so that joystick-driven games can work again. It was suggested you were the expert on these things. [11:44] slangasek: I don't have amd64 to test, sorry. [11:45] ah, I mean, no, it's i386 [11:45] * slangasek nods [11:47] ogra: is there a MIR for cbflib anywhere? [11:48] ogra: you uploaded rasmol back in June with a build-dep on it, but it's still in universe [11:51] could someone have a look at bug #258192 ? there is a patch present on the lp [11:51] Launchpad bug 258192 in dhcp3 "problem with paths and binding to ldap server" [Medium,Confirmed] https://launchpad.net/bugs/258192 [11:53] slangasek, i did ? [11:53] slangasek, hmm, must have been sponsored for LaserJock, i'l check [11:53] *i'll [11:54] well, your name is in the changelog, not much of a "sponsored" upload :) [11:55] persia: right, in fact I was planning to do the same [11:55] persia: but last week, joysticks were recognized as 'mouse', and /dev/input/js0 didn't have a hal entry at all; however, there was an -evdev fix in the meantime [11:55] pitti, Then I guess my first question is: is it faster for you to help me learn how to do it, or just to do it? [11:56] The -evdev fix made pressing a joystick button stop crashing X, but with the current HAL, there's no way for evdev to not detect joysticks as mice. [11:56] well, its just a matter of having an .fdi and making it load the mouse driver, no ? [11:56] HAL not having anything for /dev/input/js0 isn't the issue so much as HAL having an entry with input.pointer for /dev/input/eventX for joysticks. [11:56] info.capabilities = {'input', 'input.mouse'} (string list) [11:56] bah [11:57] persia: well, it is an issue [11:57] ogra, That means writing an .fdi file for *each* joystick. [11:57] persia, no, only one with a match line for every joystick [11:57] We already have about a dozen joysticks whitelisted. [11:57] pitti, well OK, but not something that I think of as intrepid-critical. [11:57] persia: before we can apply the "local foreground console access" schema, we need a hal entry with /dev/input/jsX [11:57] But that's nowhere near all of them. [11:57] ogra, Right. [11:57] And it's a crazy idea. [11:57] whats crazy about that ? [11:58] no, writing FDIs for individual joysticks is a bad idea [11:58] pitti, That makes sense. My concern is the regression that all the games don't work today. [11:58] after all, the kernel already *knows* it's a joystick [11:58] udev creates a proper device for it, after all [11:58] persia: right, if you aren't in plugdev (we don't do that by default any more) [11:59] http://pastebin.com/f1d86e7e2 is consolekit with -O0 [11:59] james_w: have you tried under valgrind yet? [11:59] pitti: Except that if I run jstest as a user from a VC after killing X, it works. If I run jstest as a user from within X it doesn't work. X seems to be grabbing exclusive access to the device. [11:59] slangasek, meh, you are right ... hmm, i would like to talk to laserjock first, he knows more about it than me but wont be around before the evening i guess [12:00] laserjock will likely be around in about 2-3 hours. [12:00] slangasek: yes, is there a way to get it to show symbols? [12:00] pitti, So, that doesn't feel like a group access issue. [12:00] ok, afternoon then :) [12:00] persia: hm, if I chmod 666 the device, jstest /dev/input/js0 works fine for me [12:01] james_w: when valgrind gives an error, it'll show the names of any functions it knows [12:01] how about using inuattach instead ? [12:01] * persia tries again [12:01] *inputatach [12:01] bah [12:01] slangasek: adding the G_SLICE and G_MALLOC env vars that the wiki page for valgrind suggests made it not crash it seems [12:01] ah, heh [12:01] slangasek: ah, the stacktrace looked the same at least [12:01] persia, it auto-maps joysticks to /dev/input/mice [12:02] where you should have access to as normal user [12:02] james_w: under valgrind? valgrind often workaround crashes but still displays errors [12:02] james_w: if using malloc instead causes it to not segfault, chances are you have an allocate/free mismatch [12:02] s/segfault/throw errors/ [12:03] like seb128 says, valgrind's job is to find memory errors /before/ they become segfaults, so yeah, you generally have to read the output [12:05] ah, it's got "Address is 8 bytes inside a block of size 12 free'd" coming from my new emit_removals_in_idle function [12:06] ah, got it I think [12:06] persia, ogra: so frankly I have no idea how -evdev works, but looking at hal debug output when plugging in a joystick might help [12:07] * ogra would recommend an inputattach handler for hal that should dtrt and map the device as a mouse [12:07] ogra: mouse? but that's what it specificallly shouldn't be... [12:08] ogra: it is a mouse in hal right now, but that's wrong [12:08] pitti, i thought it shouldnt be a keyboard [12:08] ogra: the corresponding /dev/input/eventXX thingy is a mouse in hal, and /dev/input/js0 doesn't exist at all [12:08] ah [12:08] * ogra misunderstood than [12:08] *that [12:09] ogra: anyway, so what's your idea about? [12:09] ogra: how should we teach hal about this new device? [12:10] The HAL-mapped mouse even supports all of WXYZ, so if you've some gamepads, one stick navigates, and the other scrolls. It's nice. It's just the games that I'm testing more now to make sure they aren't still broken. [12:10] my only idea would be to find device classes and make an fdi [12:10] but thats what you deliberately didnt like :) [12:11] ogra, Well, better would be to define a new info.capabilities [12:11] ogra: oh, device class is fine [12:11] ogra: I mean I didn't like FDI files with joystick vendor/product IDs [12:11] but you need to find a common denominator [12:12] which means to collect tons of lshal outputs from joystick owners first to find the right thing to match [12:12] The kernel knows what is a joystick. [12:12] So hal can find out. [12:12] And hal should publish it as a new input.joystick or similar cap. [12:12] ogra, The kernel knows it's a joystick, that's not the issue. The issue is how to present this to HAL clients. [12:13] mdz: I'm fairly certain they still need to be reuploaded when jaunty opens [12:13] mdz: I have an 'unreleased-packages' script which greps for UNRELEASED at the top of changelogs in my working trees, which means I can leave them on my disk and be reasonably certain not to forget about them [12:14] persia, well, if the kernel knows hal cqan get that info and match the fdi aganst it i think [12:14]