| jdong | pitti: eep do we have a regression of bug 95368 on our hands? | 01:06 |
|---|---|---|
| ubottu | 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 |
| jdong | seems like 4 users have reported it on Intrepid | 01:06 |
| TheMuso | .c | 01:13 |
| jdong | Password: | 01:14 |
| TheMuso | heh | 01:15 |
| slangasek | TheMuso: I guess that means you think that yes, we should fix it for intrepid? :) | 01:44 |
| TheMuso | slangasek: Yes, I'm going to look into it today. | 01:53 |
| slangasek | ok | 01:53 |
| slangasek | how is bug #274124 coming along? | 01:53 |
| ubottu | Launchpad bug 274124 in pulseaudio "Race condition in pulseaudio loading for GNOME session" [High,Confirmed] https://launchpad.net/bugs/274124 | 01:53 |
| slangasek | will we get an upload today? | 01:53 |
| TheMuso | slangasek: Just have to slap the solution into the package. On my agenda also. | 02:07 |
| ScottK | 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 |
| ubottu | Launchpad bug 207473 in hal "Screen brightness double level changes" [Medium,Confirmed] https://launchpad.net/bugs/207473 | 02:32 |
| ScottK | slangasek: Would you please accept milter-greylist? | 02:33 |
| === jamesh__ is now known as jamesh | ||
| slangasek | ScottK: done | 03:15 |
| ScottK | slangasek: Thanks. That's the libspf2 transition we discussed at the last release meeting done then. | 03:16 |
| slangasek | yep \o/ | 03:16 |
| jdong | setting up Gutsy VM's really takes you back.... | 03:21 |
| jdong | it's amazing how much we've progressed in just a few release cycles. | 03:22 |
| calc | slangasek: sorry i thought we were supposed to get special approval for any upload during final freeze | 04:17 |
| TheMuso | slangasek: Just uploaded the pulseaudio race condition work-around. | 04:22 |
| persia | TheMuso, Should that cover device recognition as well, or just desktop sounds? | 04:26 |
| TheMuso | persia: just the desktop login sound race condition. | 04:26 |
| persia | OK. I'll file a bug then. Thanks. | 04:26 |
| TheMuso | persia: Whats the problem? | 04:27 |
| persia | 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 |
| TheMuso | persia: That could be the race in effect there. | 04:28 |
| TheMuso | i.e canberra-gtk-play has the onboard card, so pulse can't grab it. | 04:29 |
| persia | That's what I was thinking. I'll retest with the new one before I file the bug then. | 04:29 |
| TheMuso | persia: What session manager is this with? gnome-session, or something for mobile? | 04:29 |
| persia | gnome-session : this is my primary laptop. | 04:29 |
| TheMuso | Ok then. | 04:29 |
| persia | I think -mobile uses gnome-session as well, and -mid doesn't use pulse. | 04:30 |
| TheMuso | Right. | 04:30 |
| * persia 's -mobile HW is currently on loan | 04:30 | |
| * TheMuso nods. | 04:30 | |
| persia | 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 |
| TheMuso | persia: Right. | 04:31 |
| persia | linux-rt and friends uploaded. | 04:41 |
| ScottK | 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 |
| ubottu | Launchpad bug 286176 in clamav "FFe Request for Clamav 0.94.1 RC" [Undecided,New] https://launchpad.net/bugs/286176 | 04:42 |
| ScottK | slangasek: What else would you like to see in the FFe? | 04:42 |
| ScottK | slangasek: I went ahead and uploaded it so you can review/accept/reject from the queue | 04:55 |
| slangasek | 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:02 |
| slangasek | TheMuso: thanks, will review :) | 05:04 |
| slangasek | ScottK: right, I'll have a look shortly | 05:04 |
| ScottK | slangasek: I'm heading to bed, so I guess I'll find out what you decided in the morning. | 05:18 |
| slangasek | persia: I'm a bit confused by the linux-rt upload; the changelog seems to bear no relation to the previous version? | 05:49 |
| slangasek | seems to have motu-release ack though, so approving (and closing bug #281276 by hand) | 05:49 |
| ubottu | Launchpad bug 281276 in linux-rt "Upgrade linux-rt to 2.6.27" [Undecided,Confirmed] https://launchpad.net/bugs/281276 | 05:49 |
| persia | 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 |
| slangasek | hum, ok | 05:49 |
| persia | 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:50 |
| slangasek | btw, it appears that bug #229499 remains unfixed in this upload | 05:51 |
| ubottu | 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 |
| slangasek | (the only linux-rt bug that was targeted to intrepid) | 05:51 |
| persia | Bother. Thanks for pointing that out. | 05:52 |
| StevenK | slangasek: I've just uploaded linux-lpia-meta, if you'd like to cast your eyes over it | 05:57 |
| === viviersf{weekend is now known as viviersf | ||
| slangasek | StevenK: accepted, thanks | 06:34 |
| StevenK | slangasek: Thanks! | 06:42 |
| === tkamppeter_ is now known as tkamppeter | ||
| pitti | Good morning | 07:05 |
| * wgrant escapes quickly. | 07:05 | |
| Treenaks | hi pitti | 07:05 |
| * Hobbsee throws pitti a gummybear, and a bit of chocolate cake | 07:06 | |
| pitti | 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 |
| TheMuso | pitti: right. | 07:06 |
| pitti | jdong: it has never really been fixed | 07:07 |
| dholbach | good morning | 07:13 |
| Hobbsee | morning dholbach | 07:14 |
| dholbach | hi Hobbsee | 07:14 |
| NCommander | directhex, ping | 07:20 |
| tkamppeter | pitti, I have fixed an important bug in the CUPS package (bug 286048) on the Debian BZR. | 07:22 |
| ubottu | 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 |
| pitti | tkamppeter: saw your mail; I'm currently building the package | 07:22 |
| directhex | NCommander, be quick, i need to go to work in 8 minutes | 07:22 |
| NCommander | directhex, how's hardware support on ia64 | 07:22 |
| NCommander | 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 |
| tkamppeter | pitti, did the release team already accept it? | 07:23 |
| directhex | NCommander, AFAIK pretty good (i run SLE on the kit at work) | 07:23 |
| NCommander | directhex, will you be willing to smoke test the ia64 kernel once I finish rebasing? | 07:23 |
| pitti | tkamppeter: I need to upload it first :) and yes, I'll accept it afterwards (it is your upload, I'm just sponsoring) | 07:23 |
| directhex | NCommander, i doubt i'd be able to i'm afraid, it's production kit | 07:24 |
| NCommander | know where I can find someone with some spare ia64 hardware? | 07:24 |
| tkamppeter | pitti, are you in the release team? | 07:27 |
| pitti | tkamppeter: yes | 07:27 |
| tkamppeter | pitti, I have some other bugs where I am not sure whether we should make a freeze exception: | 07:28 |
| pitti | tkamppeter: if the fixes are obvious and easy, and you have packages prepared, please upload them | 07:28 |
| tkamppeter | pitti: bug #284444 | 07:28 |
| ubottu | Launchpad bug 284444 in system-config-printer "Printer Configuration Program Crashed" [Medium,Triaged] https://launchpad.net/bugs/284444 | 07:28 |
| pitti | tkamppeter: at this point, we can accept those until this afternoon, but they must *really* be safe | 07:28 |
| tkamppeter | pitti, the s-c-p fix is uploaded. | 07:36 |
| tkamppeter | pitti, after uploading I get | 07:41 |
| tkamppeter | Rejected: | 07:41 |
| tkamppeter | Signer is not permitted to upload to the component 'main' of file 'system-config-printer_1.0.5+git20080819-0ubuntu6.dsc'. | 07:41 |
| pitti | tkamppeter: oh, someone needs to extend your upload ACL for that; mdz, whom to ping for that? | 07:41 |
| tkamppeter | It is strange for me. The message which one usually gets on an after-freeze upload is different. | 07:42 |
| pitti | tkamppeter: yes, I think your upload ACLs were put in place recently, and they forgot s-c-p | 07:42 |
| tkamppeter | mdz has removed my general core-dev right, probably he assumed that my ACL is in place, but probably no one touched it. | 07:43 |
| tkamppeter | mdz, can you set the upload ACLs in Launchpad? Or did you do it already? Has Launchpad perhaps a bug? | 07:44 |
| tkamppeter | 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 |
| pitti | tkamppeter: ok | 07:49 |
| pitti | oh, happy Feisty EOL day! | 07:57 |
| pitti | kees, jdstrand: ^ happy? :) | 07:58 |
| tkamppeter | pitti, the packages are now on http://www.linuxfoundation.org/~till/tmp/ubuntu/intrepid/fe/ | 07:58 |
| tkamppeter | It is all tested, the packages actually fix the reported bugs and Ghostscript two PDF-workflow-related upstream bugs in addition. | 07:59 |
| tkamppeter | 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:00 |
| * fabbione hugs pitti | 08:01 | |
| * pitti hugs fabbione back; Padre! | 08:01 | |
| superm1 | ScottK, it's actually a kernel bug | 08:07 |
| superm1 | ScottK, caused by the way the BIOS allows for multiple different video cards | 08:07 |
| superm1 | ScottK, more or less bug 226981 | 08:07 |
| ubottu | 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:07 |
| superm1 | ScottK, i'll add the upstream kernel.org bug tracker for the bug | 08:09 |
| === MacSlow_ is now known as MacSlow | ||
| superm1 | 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 |
| ubottu | Launchpad bug 261721 in linux "X never sees brightness key release events" [High,Triaged] https://launchpad.net/bugs/261721 | 08:17 |
| NCommander | hey DktrKranz | 08:25 |
| DktrKranz | hi NCommander | 08:27 |
| NCommander | DktrKranz, I verified the GNAT packages work :-) | 08:27 |
| DktrKranz | we've finished! \o/ | 08:28 |
| DktrKranz | yes, I noticed, thanks ;) | 08:28 |
| NCommander | SO now what happens? | 08:28 |
| NCommander | (I assume you need to get the archive admins to push to -updates, right? | 08:28 |
| DktrKranz | martin already copied to updates | 08:28 |
| NCommander | WOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO | 08:28 |
| directhex | i wonder if i could convince the powers that be on the ubuntu forums to add "--prefix=/usr " to the swear filter | 08:29 |
| NCommander | :-) | 08:29 |
| NCommander | ah, it feels good to finally finish that gnat transition | 08:30 |
| DktrKranz | sure. I'll adjust the spec accordingly soon | 08:31 |
| DktrKranz | and eventually track for regressions/pending issues, just to make sure we have really finished | 08:31 |
| NCommander | Probably the first/only transition to be done entirely through -updates ;-) | 08:31 |
| NCommander | DktrKranz, the packages weren't installable. Anything at this point is an improvement | 08:31 |
| DktrKranz | I hope to avoid those in the future | 08:32 |
| NCommander | We have to make sure our version of gnat stays in sync with Debian | 08:32 |
| DktrKranz | gnat-4.2 is no longer here | 08:33 |
| DktrKranz | and I hope 4.1 will go away soon | 08:33 |
| NCommander | We can NBS it out on Jaunty | 08:33 |
| NCommander | it won't be that difficult | 08:34 |
| * NCommander just needs his MOTUship ;-) | 08:34 | |
| DktrKranz | go for it, then ;) | 08:34 |
| slangasek | I don't think you mean NBS | 08:35 |
| NCommander | er | 08:35 |
| NCommander | Just removing the rdepends and getting rid of it | 08:35 |
| * NCommander drinks his coffee | 08:35 | |
| slangasek | why are you drinking coffee at 3am? | 08:36 |
| DktrKranz | let's think of it for jaunty, maybe together with debian maint | 08:36 |
| NCommander | slangasek, cause I woke up at 12:00 | 08:36 |
| seb128 | NCommander: broken timezone! | 08:37 |
| * slangasek scratches his head | 08:37 | |
| amitk | mvo: MacSlow: new libgksu works great | 08:38 |
| MacSlow | amitk, sweet news ... thanks for the feedback! | 08:38 |
| DktrKranz | slangasek: thanks for noticing my bad upload, I was definitely under crack :) | 08:39 |
| mvo | cool, thanks amitk! | 08:39 |
| NCommander | amitk & seb128 I have a sleep disorder | 08:39 |
| directhex | 48 hour days? | 08:39 |
| slangasek | DktrKranz: that's what I'm here for... :) | 08:40 |
| DktrKranz | hehe | 08:40 |
| slangasek | NCommander: you don't think drinking coffee at 3am is a cause of disorder? | 08:40 |
| tkamppeter | 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 |
| seb128 | NCommander: stop working so much and go to bed ;-) | 08:40 |
| NCommander | seb128, I woke up after 12 hours of sleep at 0:00 | 08:40 |
| tkamppeter | pitti, the removal of the workaround is also covered by the Ghostscript mass testing which I did. | 08:41 |
| pitti | tkamppeter: gs and scp are done | 08:41 |
| MacSlow | mvo, can I mark LP #275172 fixed then? | 08:41 |
| seb128 | hey pitti! | 08:41 |
| ubottu | 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 |
| pitti | tkamppeter: does the workaround hurt for anythuing? | 08:41 |
| * pitti hugs seb128, bonjour | 08:41 | |
| * seb128 hugs pitti | 08:41 | |
| seb128 | pitti: how are you? | 08:42 |
| tkamppeter | pitti, the approval message of gs appeared some seconds ago. | 08:42 |
| MacSlow | mvo, or do we need more positive feedback about the crasher being fixed? | 08:42 |
| pitti | seb128: quite okay, and you? | 08:42 |
| seb128 | pitti: good, I got over my cold and slept enough during the weekend, ready for a GNOME marathon today ;-) | 08:42 |
| mvo | MacSlow: I think its fine to close it now we got positivie feedback and no negative | 08:42 |
| slangasek | so who here is good at debugging threading race conditions? | 08:43 |
| mvo | MacSlow: feel free to add "please reopen if you still experience this problem" or something like that | 08:43 |
| tkamppeter | 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 | |
| pitti | tkamppeter: you can't upload that either? | 08:43 |
| NCommander | slangasek, what has race conditions? | 08:44 |
| slangasek | NCommander: libgstpulse or libpulse | 08:44 |
| NCommander | Deadlock? | 08:44 |
| tkamppeter | pitti, I will try. Perhaps in the ACL only somne packages were forgotten. | 08:44 |
| slangasek | segfault on shutdown (and possibly at other times) | 08:44 |
| * NCommander winces | 08:44 | |
| NCommander | That sounds evil to fix | 08:44 |
| slangasek | well if it was trivial I wouldn't be trawling for people good at thread debugging. :) | 08:45 |
| NCommander | slangasek, is there an upstream bug? | 08:47 |
| slangasek | I have no idea | 08:47 |
| === hunger_t is now known as hunger | ||
| DktrKranz | 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 |
| ubottu | Launchpad bug 249355 in ocamlsdl "ocamlsdl and lablgl conflict over Raw" [Undecided,Fix committed] https://launchpad.net/bugs/249355 | 08:49 |
| pitti | DktrKranz: thanks, done | 08:53 |
| * DktrKranz hugs pitti | 08:53 | |
| * pitti hugs back DktrKranz | 08:53 | |
| MacSlow | mvo, should I also close all the duplicates on LP #275172 ? | 09:02 |
| ubottu | 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 |
| tkamppeter | pitti, I also cannot upload foomatic-db. Seems that the new Launchpad with ACLs is not yet installed. | 09:02 |
| pitti | bah | 09:02 |
| MacSlow | mvo, or link to the comment thread of it pointing out we've a fix in place? | 09:02 |
| mvo | MacSlow: just mark them as duplicates of the fixed one | 09:02 |
| pitti | tkamppeter: does the workaround actually hurt anything? | 09:02 |
| mvo | MacSlow: thanks for cleaning that up! | 09:03 |
| tkamppeter | 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:04 |
| tkamppeter | 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 |
| pitti | ok | 09:05 |
| superm1 | 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:06 |
| pitti | superm1: uh, sorry; I checked reverse dependencies, and there was nothing left | 09:07 |
| superm1 | that's odd. it was a recommends for mythbuntu-live | 09:07 |
| MacSlow | 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:07 |
| MacSlow | hey njpatel, sabdfl | 09:08 |
| superm1 | er by 0.30, i meant 0.31. I think 0.30 was in the archive already | 09:08 |
| pitti | superm1: FAILED: mythbuntu-meta (The source mythbuntu-meta - 0.30 is already accepted in ubuntu/intrepid | 09:08 |
| njpatel | hey hey MacSlow | 09:08 |
| pitti | superm1: oh, checkrdepends doesn't check recommends, that'd be it | 09:08 |
| superm1 | pitti, yeah i just saw i uploaded the 0.30 again by accident. 0.311 should show up now | 09:08 |
| pitti | tkamppeter: okay, uploaded | 09:09 |
| === Tonio___ is now known as Tonio_ | ||
| slangasek | superm1, pitti: mythbuntu-meta accepted | 09:37 |
| pitti | slangasek: bah, I get permission errors on the queue page again; I accepted some xfce package, but the other brings an error | 09:40 |
| pitti | slangasek: does that happen for you as well? | 09:40 |
| slangasek | I don't use the web interface except for testing :/ | 09:41 |
| slangasek | 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 |
| ubottu | Launchpad bug 271794 in fglrx-installer "Re-promote gcc-3.3 to main" [Undecided,Fix released] https://launchpad.net/bugs/271794 | 09:44 |
| === mdz_ is now known as mdz | ||
| jussi01 | anyone know where to find the file: libopenal.so.0 ? | 09:46 |
| Mithrandir | jussi01: libopenal0a: /usr/lib/libopenal.so.0 | 09:47 |
| Mithrandir | jussi01: apt-file is your friend. | 09:47 |
| jussi01 | Mithrandir: yeah, I tried it, obviously wrongly as it returned nothing... | 09:48 |
| jussi01 | jussi@Galaxy:~$ apt-file search libopenal.so.0 | 09:48 |
| jussi01 | jussi@Galaxy:~$ | 09:48 |
| jussi01 | Mithrandir: thanks though :) | 09:48 |
| cjwatson | tkamppeter: the LP database certainly *thinks* you're allowed to upload system-config-printer | 09:49 |
| cjwatson | tkamppeter: http://paste.ubuntu.com/60035/ | 09:49 |
| cjwatson | tkamppeter: looks like an LP bug, unless the ACLs were changed between that upload being rejected and me looking at them | 09:50 |
| cjwatson | (that's output from './edit_acl.py -p till-kamppeter query' in lp:~kamion/+junk/ubuntu-archive-tools) | 09:51 |
| RAOF | jussi01: That's an old and apparently horribly library. Feel free to poke upstream into linking against libopenal.so.1 | 09:53 |
| RAOF | s/y l/y buggy l/ | 09:53 |
| persia | jussi01, There was a transition to make that go away in intrepid. Did something get missed? | 09:57 |
| persia | 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 |
| RAOF | persia: Heh. | 09:58 |
| lool | mdz: Do you think the iwl3945 issue is fixed by disabling ftrace? | 09:59 |
| lool | I thought it would only affect module removals | 10:00 |
| tkamppeter | cjwatson, I got a mail from mdz that he has fixed (upodated) my ACL. | 10:00 |
| mdz | lool: there were several independent reports that the problem did not recur with -7.12 | 10:01 |
| mdz | lool: can you reproduce it? | 10:01 |
| lool | I will try to do some reboots; I couldn't get the hang reliably before though | 10:02 |
| mdz | cjwatson: the ACLs were changed between that upload being rejected and you looking at them (by me) | 10:02 |
| lool | Will confirm in the bug | 10:02 |
| jussi01 | persia: in intrepid it seems to be known as libopenal1 | 10:03 |
| wgrant | jussi01: Right, it broke ABI fairly recently. | 10:03 |
| lool | mdz: Eh just got your comment in the bug report | 10:04 |
| persia | 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 |
| jussi01 | persia: ahh... | 10:04 |
| tkamppeter | 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:11 |
| mdz | tkamppeter: good, thank you | 10:12 |
| didrocks | slangasek, pitti : I have done the fix for nautilus-share, see bug #212098 | 10:12 |
| ubottu | Launchpad bug 212098 in nautilus-share ""easy" file sharing not notifying about logout/login" [High,Confirmed] https://launchpad.net/bugs/212098 | 10:12 |
| mdz | 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 |
| slangasek | pitti: any chance that you could look at that one? | 10:15 |
| slangasek | tkamppeter: that's the system-config-printer upload that you're saying should be rejected? | 10:16 |
| tkamppeter | slangasek, yes, the 0ubuntu7. | 10:16 |
| tkamppeter | 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 |
| slangasek | ok, rejected | 10:17 |
| mdz | 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:17 |
| mdz | james_w: perhaps there's a branch where I could commit them? ;-) | 10:18 |
| === seb128_ is now known as seb128 | ||
| slangasek | I like that as an answer... :) | 10:18 |
| james_w | mdz: hopefully shortly | 10:18 |
| mdz | james_w: this is alsa-driver fwiw | 10:19 |
| tkamppeter | Ubuntu got article of the day on German Wikipedia: http://de.wikipedia.org/wiki/Wikipedia:Hauptseite | 10:21 |
| mdz | pitti: do you have a rule of thumb for when apport package hooks should go in apport itself vs. in the package? | 10:34 |
| pitti | 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 |
| pitti | slangasek: 212098> yep, will do | 10:43 |
| mdz | pitti: I've written one for alsa-base which I'm inclined to put into the package | 10:46 |
| pitti | mdz: another thing is, if it would be the only package delta, I'd also be inclined to put it into apport instead | 10:47 |
| pitti | mdz: but we have a delta anyway, so I agree, putting it into alsa-base is more appropriate | 10:48 |
| mdz | 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:48 |
| mdz | 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 |
| mdz | pitti: or if hooks should invoke other packages' hooks | 10:49 |
| pitti | 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 |
| pitti | mdz: (OTOH we'll disable apport for the final release anyway) | 10:50 |
| pitti | ok, need to rush to the post office before they close; bbl | 10:51 |
| mdz | pitti: I was planning to hold these changes until post-8.10 anyway | 10:51 |
| pitti | ah, ok :) | 10:52 |
| mdz | pitti: though, if you will upload apport anyway for some reason, then please do merge my hookutils branch | 10:52 |
| pitti | mdz: the only upload I planned so far is to disable it; but I can merge it in trunk, sure | 10:53 |
| james_w | if I see a pointer with the value 0x10 in a stacktrace, is that usually indicative of a particular problem? | 10:56 |
| slangasek | james_w: uninitialized pointer is my first guess | 11:00 |
| slangasek | second guess is "somebody took an offset from NULL" | 11:01 |
| mdz | 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 | 11:01 |
| === asac_ is now known as asac | ||
| mdz | james_w: my first guess would be "int value assigned to a pointer" | 11:01 |
| mdz | james_w: URL for the stacktrace? | 11:01 |
| persia | james_w, If you are looking at a member of a structure, the pointer to the structure is probably null. | 11:01 |
| james_w | 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:01 |
| james_w | it's only in gdb currently, I'll extract it to a file | 11:02 |
| mdz | james_w: sounds like the debugger is lying to you | 11:04 |
| mdz | it unfortunately does that a lot | 11:04 |
| james_w | damn | 11:04 |
| mdz | james_w: add a printf to dump the value of the pointer at the same spot and see what that says | 11:04 |
| * wgrant recommends the use of -O0, too. | 11:06 | |
| mdz | wgrant: indeed | 11:06 |
| wgrant | That can make gdb much less useless. | 11:06 |
| james_w | hmm, apparently valid pointer that time, but still SIGSEGV | 11:10 |
| wgrant | Valid meaning it points to something, or just doesn't look so bogus at a glance? | 11:11 |
| seb128 | james_w: try using valgrind | 11:11 |
| james_w | ah, no, it's invalid, just not as obviously as invalid as 0x10 | 11:11 |
| wgrant | valgrind is good until it starts segfaulting. | 11:11 |
| seb128 | james_w: valgrind often gives you good clues | 11:11 |
| seb128 | wgrant: it doesn't segfault often for me | 11:12 |
| slangasek | james_w: so the reason you're looking at this pointer is that it's the cause of the SEGV? | 11:12 |
| wgrant | seb128: Neither, but I've encountered a couple of particularly nasty situations where it does. | 11:12 |
| slangasek | (did you post a url to the stack trace that I missed somehow?) | 11:12 |
| ogra | 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:12 |
| ogra | *restart | 11:13 |
| slangasek | wgrant: valgrind and gdb both beat analyzing core dumps by hand, so... | 11:13 |
| wgrant | slangasek: This is true. | 11:13 |
| james_w | http://paste.ubuntu.com/60057/ | 11:13 |
| slangasek | james_w: and 'list' is the pointer that was showing as 0x10 before? | 11:15 |
| james_w | yup | 11:15 |
| james_w | I'm pretty sure at least, it was yesterday | 11:15 |
| slangasek | and this latest stack trace is after rebuilding with -O0? | 11:15 |
| james_w | no, I haven't rebuilt, I'll try that now | 11:15 |
| james_w | 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 |
| slangasek | good :) | 11:17 |
| james_w | also, is there a way from a glib program to get a thread id for the thread the code is executing in? | 11:18 |
| james_w | I wonder if I misunderstood which thread was which here | 11:18 |
| slangasek | I'm not sure any thread ID you would get from inside glib would usefully correlate to how gdb identifies your threads | 11:19 |
| slangasek | definitely needs a rebuild with -O0, the line number in the backtrace doesn't match the function name | 11:21 |
| james_w | this is a patched consolekit | 11:21 |
| james_w | bug 269651 | 11:21 |
| ubottu | Launchpad bug 269651 in consolekit "console-kit-daemon crashed with SIGSEGV in g_str_hash()" [High,In progress] https://launchpad.net/bugs/269651 | 11:22 |
| slangasek | james_w: http://launchpadlibrarian.net/18690266/consolekit_0.2.10-1ubuntu9.diff, then? | 11:26 |
| slangasek | james_w: hrm, does this happen to be on amd64? | 11:33 |
| slangasek | 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:35 |
| slangasek | OTOH, it's plausible the indices really are integers in this case | 11:37 |
| persia | 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:38 |
| james_w | slangasek: I don't have amd64 to test, sorry. | 11:44 |
| james_w | ah, I mean, no, it's i386 | 11:45 |
| * slangasek nods | 11:45 | |
| slangasek | ogra: is there a MIR for cbflib anywhere? | 11:47 |
| slangasek | ogra: you uploaded rasmol back in June with a build-dep on it, but it's still in universe | 11:48 |
| bigon | could someone have a look at bug #258192 ? there is a patch present on the lp | 11:51 |
| ubottu | Launchpad bug 258192 in dhcp3 "problem with paths and binding to ldap server" [Medium,Confirmed] https://launchpad.net/bugs/258192 | 11:51 |
| ogra | slangasek, i did ? | 11:53 |
| ogra | slangasek, hmm, must have been sponsored for LaserJock, i'l check | 11:53 |
| ogra | *i'll | 11:53 |
| slangasek | well, your name is in the changelog, not much of a "sponsored" upload :) | 11:54 |
| pitti | persia: right, in fact I was planning to do the same | 11:55 |
| pitti | 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 |
| persia | 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:55 |
| persia | 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 |
| ogra | well, its just a matter of having an .fdi and making it load the mouse driver, no ? | 11:56 |
| persia | 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 |
| pitti | info.capabilities = {'input', 'input.mouse'} (string list) | 11:56 |
| pitti | bah | 11:56 |
| pitti | persia: well, it is an issue | 11:57 |
| persia | ogra, That means writing an .fdi file for *each* joystick. | 11:57 |
| ogra | persia, no, only one with a match line for every joystick | 11:57 |
| wgrant | We already have about a dozen joysticks whitelisted. | 11:57 |
| persia | pitti, well OK, but not something that I think of as intrepid-critical. | 11:57 |
| pitti | persia: before we can apply the "local foreground console access" schema, we need a hal entry with /dev/input/jsX | 11:57 |
| wgrant | But that's nowhere near all of them. | 11:57 |
| persia | ogra, Right. | 11:57 |
| wgrant | And it's a crazy idea. | 11:57 |
| ogra | whats crazy about that ? | 11:57 |
| pitti | no, writing FDIs for individual joysticks is a bad idea | 11:58 |
| persia | pitti, That makes sense. My concern is the regression that all the games don't work today. | 11:58 |
| pitti | after all, the kernel already *knows* it's a joystick | 11:58 |
| pitti | udev creates a proper device for it, after all | 11:58 |
| pitti | persia: right, if you aren't in plugdev (we don't do that by default any more) | 11:58 |
| james_w | http://pastebin.com/f1d86e7e2 is consolekit with -O0 | 11:59 |
| slangasek | james_w: have you tried under valgrind yet? | 11:59 |
| persia | 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 |
| ogra | 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 | 11:59 |
| persia | laserjock will likely be around in about 2-3 hours. | 12:00 |
| james_w | slangasek: yes, is there a way to get it to show symbols? | 12:00 |
| persia | pitti, So, that doesn't feel like a group access issue. | 12:00 |
| ogra | ok, afternoon then :) | 12:00 |
| pitti | persia: hm, if I chmod 666 the device, jstest /dev/input/js0 works fine for me | 12:00 |
| slangasek | james_w: when valgrind gives an error, it'll show the names of any functions it knows | 12:01 |
| ogra | how about using inuattach instead ? | 12:01 |
| * persia tries again | 12:01 | |
| ogra | *inputatach | 12:01 |
| ogra | bah | 12:01 |
| james_w | 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 |
| slangasek | ah, heh | 12:01 |
| james_w | slangasek: ah, the stacktrace looked the same at least | 12:01 |
| ogra | persia, it auto-maps joysticks to /dev/input/mice | 12:01 |
| ogra | where you should have access to as normal user | 12:02 |
| seb128 | james_w: under valgrind? valgrind often workaround crashes but still displays errors | 12:02 |
| slangasek | james_w: if using malloc instead causes it to not segfault, chances are you have an allocate/free mismatch | 12:02 |
| slangasek | s/segfault/throw errors/ | 12:02 |
| slangasek | 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:03 |
| james_w | 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:05 |
| james_w | ah, got it I think | 12:06 |
| pitti | 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:06 |
| * ogra would recommend an inputattach handler for hal that should dtrt and map the device as a mouse | 12:07 | |
| pitti | ogra: mouse? but that's what it specificallly shouldn't be... | 12:07 |
| pitti | ogra: it is a mouse in hal right now, but that's wrong | 12:08 |
| ogra | pitti, i thought it shouldnt be a keyboard | 12:08 |
| pitti | ogra: the corresponding /dev/input/eventXX thingy is a mouse in hal, and /dev/input/js0 doesn't exist at all | 12:08 |
| ogra | ah | 12:08 |
| * ogra misunderstood than | 12:08 | |
| ogra | *that | 12:08 |
| pitti | ogra: anyway, so what's your idea about? | 12:09 |
| pitti | ogra: how should we teach hal about this new device? | 12:09 |
| persia | 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 |
| ogra | my only idea would be to find device classes and make an fdi | 12:10 |
| ogra | but thats what you deliberately didnt like :) | 12:10 |
| persia | ogra, Well, better would be to define a new info.capabilities | 12:11 |
| pitti | ogra: oh, device class is fine | 12:11 |
| pitti | ogra: I mean I didn't like FDI files with joystick vendor/product IDs | 12:11 |
| ogra | but you need to find a common denominator | 12:11 |
| ogra | which means to collect tons of lshal outputs from joystick owners first to find the right thing to match | 12:12 |
| wgrant | The kernel knows what is a joystick. | 12:12 |
| wgrant | So hal can find out. | 12:12 |
| wgrant | And hal should publish it as a new input.joystick or similar cap. | 12:12 |
| persia | ogra, The kernel knows it's a joystick, that's not the issue. The issue is how to present this to HAL clients. | 12:12 |
| cjwatson | mdz: I'm fairly certain they still need to be reuploaded when jaunty opens | 12:13 |
| cjwatson | 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:13 |
| ogra | persia, well, if the kernel knows hal cqan get that info and match the fdi aganst it i think | 12:14 |
| ogra | persia, i'll look for my old sidewinder later today and see what i can find out :) | 12:14 |
| wgrant | ogra: HAL needs to export it somehow. That is the key. | 12:15 |
| persia | ogra, Right, which gives us a nice simple .fdi file for xserver-xorg-input-joystick. | 12:15 |
| ogra | right | 12:15 |
| wgrant | Rather than the awfulness that is the current one. | 12:15 |
| ogra | there is one currently ? | 12:15 |
| persia | ogra, Right now, we can't do that because HAL doesn't tell us that it's a joystick. | 12:15 |
| wgrant | There is. | 12:15 |
| * ogra looks | 12:15 | |
| wgrant | See /usr/share/hal/fdi/policy/20thirdparty/10-x11-joystick.fdi | 12:15 |
| wgrant | (part of xserver-xorg-input-joystick) | 12:15 |
| ogra | ah, thats why i didnt see it :) | 12:16 |
| * ogra installs and takes a look | 12:16 | |
| * persia wishes js_demo wasn't embedded in flightgear : flightgear is just *so* big. | 12:17 | |
| ogra | split it out | 12:17 |
| ogra | we did the same for inputattach back in dapper | 12:17 |
| persia | ogra, Which problem are you trying to solve? | 12:18 |
| pitti | ah, I don't have xserver-xorg-input-joystick installed either | 12:18 |
| ogra | wgrant, that file doesnt look so bad though | 12:18 |
| ogra | though 10- might be wrong | 12:18 |
| persia | pitti, Until we export something for a sane .fdi file, that package probably isn't as useful as you'd think. | 12:18 |
| wgrant | ogra: It doesn't detect most joysticks. | 12:19 |
| ogra | thats likely to be overridden by something else | 12:19 |
| persia | (Especially because X is already getting 4 axes from /dev/input/eventX) | 12:19 |
| pitti | persia: ugh, indeed that file looks pretty useless | 12:19 |
| persia | pitti, It was tjaalton's first quick workaround when trying to deal with the problem. Having input.joystick or something would be much preferred by all. | 12:20 |
| pitti | *nod* | 12:20 |
| mdz | ogra: inputattach and perhaps something like js_demo should probably be moved into input-utils upstream | 12:24 |
| ogra | mdz, good ide, i'll take care for that in jaunty (i'll have to discuss a lot of touchscreen stuff upstream anyway) | 12:24 |
| slangasek | mvo: no bug numbers in the changelog for this update-manager upload? | 12:24 |
| persia | mdz, jstest which is the more common way to do it is part of the joystick package. | 12:25 |
| ogra | persia, xserver-xorg-input-joystick or joystick ? | 12:26 |
| james_w | ugh, this is worse that I thought | 12:26 |
| ogra | persia, it should be in xserver-xorg-input-joystick | 12:26 |
| persia | ogra, joystick. It contains jscal and jstest. Everything you want to play with a joystick. | 12:26 |
| persia | No, it should be either in joystick or in input-utils. It doesn't belong in xserver-xorg-input-joystick | 12:26 |
| persia | It uses the kernel interface, not the X interface. | 12:27 |
| mvo | slangasek: the DistUpgrade/xorg_fix_intrepid.py stuff comes from forum feedback, the glade file has a bug, sorry for that | 12:27 |
| mdz | persia: inputattach is useful for more than joysticks, and joysticks don't seem to warrant their own package apart from all other input devices (input-utils is 16k, joystick is 14k) | 12:27 |
| mvo | slangasek: there is anohter one pending, apparently the nvidia drivers do not work anymore on cpus without SSE support | 12:27 |
| mvo | so we need to test for this :/ | 12:27 |
| persia | mdz, Sure. merging joystick into input-utils seems sane to me. | 12:27 |
| slangasek | mvo: awesomesauce \o/ | 12:27 |
| ogra | mdz, it has an intuitive ame though ... thats the only pro argument i see | 12:27 |
| ogra | *name | 12:27 |
| slangasek | Riddell: is there a bug number for this scim-bridge change? | 12:28 |
| ogra | input-utils proably should provide joystick and merge all the tools in | 12:28 |
| mdz | persia,ogra: someone should mail the upstreams and see what they think | 12:29 |
| Riddell | slangasek: I don't think so, let me check | 12:30 |
| * ogra wonders if joystic is even active upstream | 12:30 | |
| ogra | the mentioned url in the package descriptopn is a dead link | 12:31 |
| slangasek | Riddell: in your language-selector upload, the changelog and the source diff say opposite things... | 12:31 |
| ogra | persia, do you know if joystick upstream is active at all ? | 12:31 |
| ogra | and if so, where ? | 12:32 |
| persia | ogra: no idea | 12:32 |
| Riddell | slangasek: scim-bridge is a continuation of bug 203334 | 12:32 |
| ubottu | Launchpad bug 203334 in scim-bridge "scim-bridge-client-qt4 requires scim" [Undecided,Fix released] https://launchpad.net/bugs/203334 | 12:32 |
| Riddell | slangasek: it not only needed scim but a running scim | 12:32 |
| pitti | Riddell: how do current langpacks look KDE wise now? | 12:33 |
| Riddell | pitti: still incomplete, but we know why and we're working around it | 12:34 |
| Riddell | slangasek: hmm, best reject that langauge-selector upload until ArneGoetje appears so I can clarify what's actually needed | 12:35 |
| slangasek | Riddell: ok, done | 12:35 |
| slangasek | Riddell: the kubuntu-meta change should be ok to let through though, right? It doesn't depend on the language-selector change in any way? | 12:36 |
| persia | pitti, What did you test with jstest? I just updated to latest everything, and when I'm running X, both jstest and js_demo show the device, but don't receive any events. When I'm not running X, both show events. I continue to suspect that evdev having an exclusive lock on /dev/input/eventX is blocking events on /dev/input/jsX | 12:37 |
| Riddell | slangasek: correct (it's also a request from arne and I don't have any details but I do as I'm told :) | 12:39 |
| * slangasek winces | 12:39 | |
| pitti | persia: well, I move the stick and press the buttons, and I see the corresponding actions in the output numbers | 12:40 |
| persia | pitti, That's precisely what I'm not seeing. Which architecture? | 12:41 |
| pitti | persia: i386 | 12:41 |
| persia | Hmm. I'm amd64. I wonder if that might affect it. | 12:41 |
| pitti | persia: for me, "xinput list" doesn't change if I plug in the joystick; does it for you? | 12:42 |
| pitti | persia: and do you have gameport or usb? | 12:42 |
| pitti | persia: I have usb | 12:42 |
| slangasek | er... this wouldn't have any relation to the broken xinput headers on amd64 that were fixed the other day, would it? | 12:42 |
| wgrant | pitti: Do you have -joystick installed? | 12:42 |
| mdz | mvo: comments on bug 267749? | 12:42 |
| wgrant | slangasek: No. | 12:42 |
| ubottu | Launchpad bug 267749 in libflashsupport "Please remove libflashsupport source+binary from archive" [High,Fix released] https://launchpad.net/bugs/267749 | 12:42 |
| slangasek | ok | 12:42 |
| pitti | wgrant, persia: no, I don't have x-x-input-joystick installed | 12:43 |
| wgrant | pitti: I'm on i386 and my USB joystick shows up and does annoying mousey things. | 12:43 |
| wgrant | pitti: That would do it. | 12:43 |
| pitti | well, I don't *want* it do mouseish things, I want it to work in games :) | 12:43 |
| persia | wgrant, I also don't have xserver-xorg-input-joystick installed. | 12:43 |
| pitti | but I think that's pretty independent | 12:43 |
| pitti | persia: ideally /dev/input/eventXX would be the joystick "mouseish" thing for X, while /dev/input/js0 is the game thingy | 12:43 |
| persia | pitti, I do show my device in xinput list | 12:43 |
| wgrant | persia: Do you have some other fdi file, then? | 12:43 |
| persia | wgrant, Nothing non-default. | 12:44 |
| wgrant | Hmm. | 12:44 |
| * persia tries a different joystick | 12:44 | |
| * pitti installs x-x-i-j and compares | 12:44 | |
| mvo | mdz: sorry, the answer is yes, but I wll add code that ensures it goes away even when the user decides to skip the cleanup | 12:44 |
| mvo | mdz: it looks like it does not have any useful purpose anymore | 12:44 |
| mvo | mdz: s/code/a entry in the config/ | 12:45 |
| mdz | mvo: in fact it is actively harmful | 12:45 |
| mvo | right, one more reason than | 12:45 |
| persia | Well. I tried three joysticks. Either I win the .fdi lottery or pitti does. | 12:45 |
| persia | All of mine behave the same : xinput list changes, and jstest doesn't work. | 12:46 |
| pitti | +"Mega World USB Game Controllers"id=9[XExtensionKeyboard] | 12:46 |
| pitti | persia: with x-x-i-j installed, I get that in xinput list ^ | 12:46 |
| persia | pitti, Odd. I really don't have that package installed, and my joysticks work in X, and don't work in games. | 12:47 |
| ogra | mdz, it might still be useful on networked connections in ltsp, i didnt find the time to test it yet, but in that case it cn go into a PPA | 12:47 |
| pitti | persia: but even with the package installed, jstest still works | 12:47 |
| pitti | persia: you sure you chmod 666'ed the device? | 12:47 |
| * ogra actually tries it out in a vm *now* | 12:48 | |
| persia | pitti, well, I'm in plugdev. | 12:48 |
| persia | chmod 600 gives a different issue : jstest reports "Permission denied". | 12:48 |
| * persia tries with 666 just in case some other user is critical to making this work | 12:49 | |
| pitti | persia: ok I'm not in plugdev, but 660 should be fine for you then | 12:49 |
| pitti | persia: right, you'd get EPERM with insufficient privileges, not a non-working jstest | 12:50 |
| pitti | bah, and why did my X crash when I purged x-x-i-j ... | 12:50 |
| jcristau | with a grabbed device, you'd get a non-working jstest | 12:50 |
| persia | pitti, Yeah, changing to 666 doesn't make any difference. | 12:50 |
| jdstrand | pitti: re 'happy?'> \o/ | 12:51 |
| persia | jcristau, So the question becomes : why isn't evdev grabbing pitti's joystick? | 12:51 |
| pitti | persia: erm, it does, if I have -input-joystick installed | 12:51 |
| persia | Does anyone else have a joystick? | 12:51 |
| pitti | mouse emulation works fine | 12:51 |
| jdstrand | pitti: though, it always does make me a little sad when one is EOL'd... | 12:51 |
| ogra | persia, in some moving box in the basement | 12:51 |
| persia | pitti, Mouse emulation works fine for me too, but I don't have to install xserver-xorg-input-joystick. | 12:52 |
| jdstrand | (not from a security support standpoint of course!) | 12:52 |
| * ogra goes digging | 12:52 | |
| pitti | I just recently bought an USB one, it's all dosbox' fault | 12:52 |
| * persia installs an i386 box | 12:52 | |
| pitti | intrepid's version is too good, it runs TIE fighter and X-Wing | 12:52 |
| pitti | (Wing Commander, too) | 12:52 |
| wgrant | persia: On i386 a USB one is grabbed by evdev if I have -joystick enabled. | 12:52 |
| wgrant | I wonder if a HAL restart might be required to pick up the new file? | 12:53 |
| pitti | wgrant: no, that should work now | 12:53 |
| persia | wgrant, But I don't have -joystick installed, and I rebooted even. | 12:53 |
| wgrant | Blurgh. | 12:54 |
| pitti | persia, wgrant: http://paste.ubuntu.com/60085/ is what I get from hal when plugging it in | 12:54 |
| ogra | http://paste.ubuntu.com/60086/ | 12:54 |
| ogra | thats what i get from dmesg | 12:54 |
| persia | pitti wins | 12:54 |
| ogra | yeah, hal sees input,input.mouse | 12:55 |
| * wgrant grabs his joystick again. | 12:55 | |
| pitti | ogra: oh, a Sidewinder, the only good MS product ever :) | 12:56 |
| ogra | yeah | 12:56 |
| pitti | ogra: unfortunately mine has a gameport connector and thus doesn't work any more :( | 12:56 |
| ogra | well, they ake some good mice and keyboards as well :) | 12:56 |
| ogra | though i dont own any :) | 12:56 |
| * wgrant feels dirty to now have two old Microsoft input devices plugged in. | 12:57 | |
| persia | pitti, Why doesn't it work? Is it just that your hardware doesn't support it? Do you want a USB gameport? | 12:57 |
| wgrant | pitti: Where'd you pull that hal log from? | 12:57 |
| ogra | wgrant, why, thats the only area where they dont produce crap :) | 12:57 |
| ogra | --no-daemon --debug ? | 12:57 |
| * persia likes some microsoft mice | 12:57 | |
| pitti | wgrant: sudo /etc/init.d/hal stop; sudo hald --verbose=yes --daemon=no | 12:57 |
| wgrant | ogra: Indeed, this Basic Optical Mouse and SideWinder 2 have lasted well. | 12:57 |
| ogra | or dbus-monitor | 12:58 |
| wgrant | pitti: Right, just wondering if it logged somewhere by default. | 12:58 |
| wgrant | Thanks. | 12:58 |
| pitti | persia: well, I played with lots of module options of my old SB 128 (es1371), but it just wouldn't appear | 12:58 |
| persia | pitti, When was this? gameport joysticks shouldn't have worked for Edgy, but should have worked for Dapper and Feisty (and earlier and later) | 12:59 |
| pitti | anyway, I let you figure this out, need to turn my head towards some RC bug fixes, sorry | 12:59 |
| pitti | persia: like three weeks ago, under intrepid on my amd64 test box | 12:59 |
| persia | No problem. Thanks for testing. That it works fine for you indicates it's probably something you can't fix :) | 12:59 |
| pitti | persia: well, it doesn't work perfectly just yet | 12:59 |
| pitti | persia: I'd need the device to appear in hal, so that we can attach dynamic ACLs to it | 12:59 |
| pitti | persia: but apparently you have a completely different problem then :/ | 13:00 |
| ogra | hmm | 13:00 |
| persia | pitti, yeah. I'll take a look at gameports again next :) | 13:00 |
| ogra | ogra@osiris:~$ sudo jstest -c /dev/input/event12 | 13:00 |
| ogra | Driver version is 0.8.0. | 13:00 |
| ogra | Joystick (Unknown) has 2 axes (X, X) | 13:00 |
| ogra | Segmentation fault | 13:00 |
| ogra | neat | 13:00 |
| wgrant | Nice! | 13:00 |
| ogra | ogra@osiris:~$ sudo jscal -c /dev/input/event12 | 13:01 |
| ogra | jscal: error getting version: Invalid argument | 13:01 |
| pitti | persia: I just gave up and bought a Thrustmaster for some 20 bucks | 13:01 |
| ogra | thats even better | 13:01 |
| wgrant | ogra: What if you try /dev/input/js0? | 13:01 |
| pitti | ogra: are you really supposed to use the "eventXX" ones? /dev/input/jsX WFM | 13:01 |
| persia | ogra, It doesn't work with the event interfaces | 13:01 |
| ogra | wgrant, nothing | 13:02 |
| wgrant | jstest works here, as well as working the pointer. | 13:02 |
| ogra | it doesnt segfault though | 13:02 |
| wgrant | ogra: Without -c? | 13:02 |
| ogra | haha | 13:02 |
| * ogra just notices js0 is bound to his tuchscreen | 13:02 | |
| ogra | thats so wrong | 13:02 |
| wgrant | persia: So I can have my joystick working as both a pointer and in jstest. | 13:03 |
| ogra | ok, works fine with js1 | 13:03 |
| persia | wgrant, Right. I'm becoming convinced it's an architecture thing. I'm just waiting for the i386 install to complete, and I'll confirm that. | 13:03 |
| pitti | didrocks: oh, does the "restart your session" messagebox *only* has OK? it should have something like "Restart" "Cancel" | 13:03 |
| wgrant | persia: It could still be a config issue. | 13:03 |
| pitti | persia: my amd64 box still has an ancient ubuntu install, but I will reinstall it with the RC candidates for testing anyway | 13:04 |
| pitti | persia: so then I can test it there | 13:04 |
| wgrant | But I've seen so much 64-bit unsafeness in X stuff lately I wouldn't be entirely surprised. | 13:04 |
| pitti | persia: s/ancient ubuntu/ancient intrepid/ | 13:04 |
| jcristau | persia: what does lshal say about your joystick (x11_driver, in particular)? | 13:04 |
| ogra | ancient intrepid ? | 13:04 |
| ogra | heh | 13:04 |
| persia | jcristau, evdev | 13:05 |
| pitti | ogra: well, it's still from the day when I got my dell docking station and stopped using my amd64 box as a work station | 13:05 |
| didrocks | pitti: non, it as a "closed" button also | 13:05 |
| didrocks | no* | 13:06 |
| ogra | yeah, desktops for working are so last century :) | 13:06 |
| jcristau | persia: there's your problem then | 13:06 |
| === davmor2 is now known as davmor2_lunch | ||
| pitti | didrocks: ah; I'll test it now | 13:06 |
| persia | jcristau, Yep. But that it isn't happening for pitti and wgrant makes it more interesting. | 13:06 |
| jcristau | persia: if it said joystick, jstest would probably work.. | 13:06 |
| jcristau | persia: that just means their joystick is matched by x-x-i-joystick's fdi file, and yours isn't | 13:06 |
| jcristau | afaict | 13:07 |
| tjaalton | probably so | 13:07 |
| ogra | http://paste.ubuntu.com/60089/ | 13:07 |
| ogra | mine neither | 13:07 |
| persia | jcristau, Except it's working for pitti when x-x-i-j *isn't* installed. | 13:07 |
| wgrant | When my joystick wasn't matched by -joystick's fdi file, it wasn't recognized by evdev either. | 13:07 |
| wgrant | So it worked. | 13:07 |
| pitti | persia: well, hang on | 13:07 |
| wgrant | Somehow persia's is recognised by evdev. | 13:08 |
| pitti | persia, jcristau: If I install x-x-i-j, I get js mouse emulation in X.org, and jstest works | 13:08 |
| persia | All *three* of mine are recognised by evdev | 13:08 |
| persia | pitti, And if you uninstall it? | 13:08 |
| pitti | persia, jcristau: if I don't have x-x-i-j, I don't get js mouse emulation in X.org, and jstest works | 13:08 |
| * ogra adds his to the fdi | 13:08 | |
| pitti | so for me it behaves just fine, AFAICS | 13:08 |
| wgrant | pitti: But you don't see it in `xinput list` in the latter case? | 13:08 |
| doko | hmm, wondering why "file <java class file> just prints "data" | 13:08 |
| persia | For me, I get mouse emulation and jstest doesn't work, regardless of whether x-x-i-j is installed. | 13:08 |
| pitti | wgrant: I do | 13:08 |
| jcristau | pitti: ok, so x-x-i-evdev doesn't recognize yours | 13:09 |
| jcristau | might depend what buttons/axes it pretends to have | 13:09 |
| pitti | jcristau: the only real problem for me is that hal doesn't know about /dev/input/js0, but that's entirely unrelated to x.org | 13:09 |
| persia | Mine tend to have a lot of both. | 13:09 |
| mdz | slangasek: my rfkill issue is mysteriously resolved. is yours? | 13:09 |
| slangasek | mdz: which one? | 13:09 |
| slangasek | the "hw switch breaks the driver" one, or the "sysfs interface changed out from under us" one? | 13:10 |
| pitti | RF kill doesn't work with network-manager (did work in hardy) | 13:10 |
| mdz | slangasek: the one I described in 193170 | 13:10 |
| mdz | slangasek: er, 193970 | 13:10 |
| ogra | http://paste.ubuntu.com/60090/ there we go | 13:10 |
| mdz | slangasek: i.e., that the state in sysfs didn't change when I flipped the switch | 13:10 |
| pitti | mdz: should that be /sys/class/rfkill/rfkill0/state ? | 13:11 |
| pitti | it's "2" for me regardless of the switch position | 13:11 |
| ogra | persia, add yours to the fdi and check again | 13:12 |
| mdz | pitti: see perseus:[/sys/class/rfkill] # toggle kill switch | 13:12 |
| mdz | er | 13:12 |
| slangasek | mdz: nope, not fixed here | 13:12 |
| mdz | pitti: see https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/linux/+bug/193970 | 13:13 |
| ubottu | Launchpad bug 193970 in linux-ubuntu-modules-2.6.24 "iwl3945 | iwl4965: Wireless can't be activated after disabling kill switch" [Undecided,New] | 13:13 |
| persia | ogra, That's not a useful solution. That only fixes it for my equipment. We're not going to get a complete list. | 13:13 |
| mdz | argh, https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/linux/+bug/193970/comments/60 | 13:13 |
| ogra | persia, not for intrepid, no | 13:13 |
| mdz | pitti,slangasek: /proc/version_signature? | 13:13 |
| ogra | persia, but for intrepid adding the ones we know about would already help a bit | 13:13 |
| jcristau | persia: right. the fix is to have hal tell us what's a joystick | 13:13 |
| pitti | mdz: 2.6.27-7.12-generic | 13:13 |
| persia | ogra, We're never going to get a complete list. Trying to do so is sisyphean. | 13:13 |
| slangasek | Ubuntu 2.6.27-7.10-generic | 13:13 |
| ogra | persia, but its not the time to add heavy hacks to hal now | 13:14 |
| pitti | mdz: (just booted a couple of times to verify the iwl3945 boot hang) | 13:14 |
| persia | ogra, For x-x-i-j, I slightly agree with you. For my problem, I completely disagree. | 13:14 |
| mdz | pitti: what was the state of the switch when you booted? | 13:14 |
| ogra | i totaly agree with you, just not with the timeframe :) | 13:14 |
| pitti | mdz: killing enabled, i. e. no wifi (it's usually docked and on eth, so I don't need it) | 13:14 |
| persia | ogra, The solution might be to add a note to the release notes that Intrepid is known not to work for gaming with a number of joysticks. I just want to avoid complaints. Fixing it would be nice, but it's not the only option. | 13:15 |
| ogra | for intrepid it seems sanet to me to have the ones we know about added to the fdi | 13:15 |
| ogra | *sanest | 13:15 |
| mdz | I usually boot with it enabled (wifi disabled), but this time I booted with it disabled because I happened to have been testing for bug 258804 | 13:15 |
| ubottu | Launchpad bug 258804 in linux "WARNING: at /build/buildd/linux-2.6.26/drivers/usb/serial/usb-serial.c:322 serial_write_room+0x72/0x80 [usbserial]()" [Unknown,Confirmed] https://launchpad.net/bugs/258804 | 13:15 |
| persia | ogra, If you like. I think that's a waste of time, as there are more types of joysticks than most other accessories. | 13:15 |
| pitti | mdz: right, same for me (wifi disabled almost every time) | 13:15 |
| mdz | pitti: maybe boot with it in the other state to see if that's a factor? | 13:15 |
| pitti | mdz: trying | 13:15 |
| liw | mvo, ping | 13:16 |
| ogra | persia, well, the kernel seems to know its a joystick here, no matter what x driver sits on top ... how does your dmesg look like if you plug it ? | 13:17 |
| liw | mvo, https://bugs.launchpad.net/ubuntu/+source/system-cleaner/+bug/285657 -- do you have comments on that bug in system-cleaner? | 13:17 |
| ubottu | Launchpad bug 285657 in system-cleaner "system-cleaner - should not offer or warn when removing one of the last two installed kernel versions" [Undecided,New] | 13:17 |
| mvo | liw: let me have a look | 13:18 |
| mdz | Keybuk: any luck with confirming 263059? | 13:18 |
| Keybuk | mdz: still downloading updates | 13:18 |
| * Keybuk really wants a faster internet connection | 13:19 | |
| pitti | mdz: 263059 looks pretty good now, several positive tests | 13:19 |
| persia | ogra: http://paste.ubuntu.com/60092/ would be a sample | 13:20 |
| Keybuk | I don't really understand why ftrace would break this though | 13:20 |
| ogra | woah | 13:20 |
| ogra | unplugging my joystick killed X | 13:20 |
| Keybuk | unless you have a tracer, isn't it just 5 no-op instructions? | 13:20 |
| lfaraone | dholbach: ping | 13:20 |
| persia | ogra, See, that happened for pitti also. Doesn't happen for me. | 13:20 |
| ogra | persia, [ 972.048320] input,hidraw0: USB HID v1.00 Joystick | 13:20 |
| ogra | i think the kernel knows enough to make hal set a capability here | 13:20 |
| pitti | for me it crashed when unplugging joystick and purging x-x-i-j | 13:20 |
| ogra | for me it just crashed when unplugging | 13:21 |
| * ogra tries again | 13:21 | |
| mdz | pitti: yes, I went ahead and marked it closed, but rtg and Keybuk are skeptical | 13:21 |
| ogra | hmm, this time it survived | 13:21 |
| persia | I can attach and unattach : the only annoyance is EV_ABS interfering with the mouse pointer until I touch the appropriate axis. | 13:21 |
| mvo | liw: in the past we did not remove kernels at all because of concerns like this. but now with the last-known-good kernel feature I think its much less critical | 13:21 |
| Keybuk | mvo: that feature is disabled in intrepid | 13:22 |
| mvo | is it? | 13:22 |
| liw | Keybuk, the last-known-good-kernel feature? | 13:22 |
| mdz | mvo: that was the plan, but it wasn't ready for 8.10 | 13:22 |
| ogra | hmm, doesnt happen again | 13:22 |
| liw | ok, then it sounds like system-cleaner should not remove kernel images | 13:22 |
| mvo | liw: ok, please take back what I just said | 13:22 |
| liw | mvo, do you agree with not removing kernels? | 13:22 |
| mdz | liw: I think it should. if it doesn't, nothing else will. | 13:22 |
| ogra | bah, now i have to boot all my VMs again | 13:23 |
| mvo | maybe not select it by default? | 13:23 |
| mvo | (select for removal by default) | 13:23 |
| mdz | liw: this was actually the original reason that *both* system-cleaner and last-good-boot were conceived! | 13:23 |
| mvo | mdz: update-manager will too, all but the running one on upgrade | 13:23 |
| pitti | mdz: updated 193970 | 13:23 |
| mvo | (all of the previous release) | 13:23 |
| mdz | mvo: oh, good, I didn't relaize that | 13:23 |
| mvo | I think it should be fine because it keeps the running one | 13:24 |
| liw | so would it be ok if system-cleaner keeps it hands off kernels, for now, and we rely on update-manager to get rid of them on upgrade? until we can figure out a reliable heuristic for this | 13:25 |
| dholbach | lfaraone: pong | 13:27 |
| mdz | liw: I think update-manager's heuristic is a pretty good one | 13:27 |
| mdz | liw: keep the most recent kernel, plus the one which was being used when that one was installed | 13:27 |
| ogra | mdz, fyi flash sound in ltsp works fine without libflashsupport | 13:28 |
| cjwatson | I agree that system-cleaner should remove kernels, just be a little more selective about it | 13:29 |
| cjwatson | this is system-cleaner's highest-priority purpose | 13:29 |
| liw | for me, the reason for system-cleaner to exist is to add relatime to fstab, but I seem to be in the minority | 13:30 |
| mvo | ogra: is removal of libflashsupport ok for ltsp too? | 13:30 |
| liw | ok, I'll change system-cleaner to follow update-manager's heuristic | 13:30 |
| ogra | mvo, yep, just noted that on the bug | 13:30 |
| mvo | ogra: cool, thanks | 13:30 |
| cjwatson | there are certainly other important reasons, but that's why it got cranked up the foundations agenda | 13:31 |
| mdz | liw: what does relatime have to do with system-cleaner? | 13:31 |
| liw | mdz, system-cleaner adds (or offers to) relatime to ext2/ext3 filesystems in fstab if not there already | 13:31 |
| ogra | .oO(would be nice if system cleaner could display the package description at least, i have a lot stuff in there of which i dont know what it actually is) | 13:31 |
| mdz | liw: why? | 13:32 |
| liw | ogra, that's a fair request, please file a bug about it | 13:32 |
| ogra | liw, will do | 13:32 |
| cjwatson | mdz: it is useful to have something that does the things that update-manager does post-upgrade in case you didn't actually use update-manager | 13:32 |
| Keybuk | is it useful to have two implementations of that though? | 13:32 |
| mdz | cjwatson: but update-manager doesn't mess with relatime afaik | 13:32 |
| cjwatson | /usr/lib/python2.4/site-packages/DistUpgrade/DistUpgradeQuirks.py: " add the relatime option to ext2/ext3 filesystems on upgrade " | 13:33 |
| lfaraone | dholbach: Hey, how would I register a DocBook collection of docs for FooPackage with yelp/scrollkeeper so that they show up in yelp? (for documentation-only packages) | 13:33 |
| liw | Keybuk, no, but having it in both tools sharing the same implementation should be ok | 13:33 |
| mdz | cjwatson: interesting, I don't remember that happening on my systems | 13:33 |
| Keybuk | liw: agree | 13:33 |
| cjwatson | Keybuk: ultimately update-manager and system-cleaner should be built from the same source | 13:33 |
| liw | Keybuk, ergo, python-fstab ;-) | 13:33 |
| cjwatson | same way as ubiquity and oem-config should be built from the same source | 13:33 |
| mdz | oh, it was added in intrepid after I had already upgraded | 13:33 |
| mvo | mdz: if you upgraded early it may have not been around | 13:34 |
| cjwatson | https://wiki.ubuntu.com/CleanupCruft mentions this | 13:34 |
| liw | mdz, see, you need to run system-cleaner... :) | 13:34 |
| persia | lfaraone, Probably a better question in #ubuntu-motu | 13:34 |
| dholbach | lfaraone: best to ask the fine people in #ubuntu-doc | 13:34 |
| mvo | cjwatson: liw and I should have a session about this at next UDS | 13:34 |
| Keybuk | interesting | 13:34 |
| cjwatson | yes. noted | 13:34 |
| mdz | liw: it should be installed by default and run automatically; if users have to go out and find it, then it will not be effective | 13:34 |
| Keybuk | so the update-manager quirks only get run if you actually do a dist upgrade | 13:35 |
| cjwatson | it is installed by default now | 13:35 |
| Keybuk | so all the post-beta quirks get missed if you upgrade at beta? | 13:35 |
| mvo | Keybuk: yes | 13:35 |
| cjwatson | Keybuk: this is why they need to be accessible some other way too | 13:35 |
| Keybuk | do we announce new quirks anywhere so people can manually fix their systems? | 13:35 |
| cjwatson | release notes | 13:35 |
| lfaraone | dholbach: ah, kk. | 13:35 |
| mvo | Keybuk: all that u-m does needs to go into the release notes too for people using apt-get | 13:35 |
| ogra | liw, bug 286394 for you | 13:36 |
| ubottu | Launchpad bug 286394 in system-cleaner "system-cleaner should display the package descriptions on demand" [Wishlist,New] https://launchpad.net/bugs/286394 | 13:36 |
| liw | ogra, vielen Dank | 13:36 |
| lfaraone | persia: these are -docs packages for packages in main. | 13:36 |
| Keybuk | cjwatson: or have something run as part of an ordinary upgrade that sorts out quirks | 13:36 |
| ogra | :) | 13:36 |
| mvo | right | 13:36 |
| pitti | mvo: what's the status of the compiz screensaver fix? you wanted to do the upload yourself, you said? | 13:37 |
| pitti | mvo: (I have 1:0.7.8-0ubuntu5 prepared and tested, FYI) | 13:38 |
| liw | mvo, next question: https://bugs.launchpad.net/bugs/285746 -- I don't think there's much we can do to distinguish obsolete packages and those installed via dpkg -i, or some other way bypassing sources.list, is there? | 13:38 |
| ubottu | Launchpad bug 285746 in system-cleaner "System cleaner removes explicitly installed third-party packages" [Undecided,New] | 13:38 |
| mdz | liw: if the user intentionally disables relatime, will system-cleaner notice and leave it alone? | 13:38 |
| mvo | pitti: see #ubuntu-release - I think the compiz changes have problems, they case white-screen screensavers on nvidia | 13:38 |
| pitti | mvo: oh, darn | 13:39 |
| mvo | pitti: I posted a fix for xserver-xorg-core that should DTRT | 13:39 |
| liw | mdz, if users tells system-cleaner to ignore relatime, then system-cleaner will remember that and not enable it itself | 13:39 |
| mvo | pitti: now its a bit scary to change that now so I did not upload into into intrpeid without bryce or tjaalton looking at it first (I asked firday for that) | 13:39 |
| pitti | mvo: alright, thanks for the heads-up | 13:39 |
| mvo | pitti: we could go with the compiz change, that would be not worse than what we had in hardy (+plus that it seems like the wrhite screen problem is easier to trigger with the latest nvidia drivers, but that is just a theory) | 13:40 |
| mdz | liw: so if I disable it manually, system-cleaner will offer to put it back the next time it runs, but only once (if I say no)? | 13:40 |
| liw | mdz, correct | 13:41 |
| pitti | mvo: uh, _usr_bin_update-notifier.117.crash | 13:55 |
| pitti | mvo: I thought it wouldn't run for the guest session? | 13:55 |
| mvo | pitti: it should not :( | 13:55 |
| * pitti files it | 13:55 | |
| mvo | pitti: please | 13:55 |
| mvo | thanks | 13:55 |
| pitti | mvo: ah, already there, bug 285075 | 13:56 |
| ubottu | Bug 285075 on http://launchpad.net/bugs/285075 is private | 13:56 |
| === viviersf is now known as viviersf{gone} | ||
| liw | mvo, so, is there a way to distinguish between a no-longer-available-via-apt-get package and a user-installed-via-dpkg-or-outside-apt package? | 13:58 |
| pitti | mvo: I did some duplication cleanup | 13:58 |
| mvo | liw: not right now we would have to add code to do that | 13:58 |
| mvo | liw: something worth to discuss though | 13:58 |
| liw | mvo, add code where? apt? | 13:58 |
| mvo | liw: libapt, yes | 13:58 |
| liw | mvo, right, so there's nothing system-cleaner can do about it right now | 13:59 |
| mvo | pitti: thanks | 13:59 |
| mvo | liw: nothing that I can think of at least | 13:59 |
| liw | mvo, I'll note that in 285888, thanks | 13:59 |
| liw | er, not that bug | 13:59 |
| liw | mvo, 285746 -- that one, I'm getting confused with this deluge of bugs :) | 14:00 |
| === davmor2_lunch is now known as davmor2 | ||
| mvo | pitti: hm, that is a strange bt - does yours show similar charackeristics? | 14:01 |
| pitti | mvo: I didn't have a symbolic one, but the bug description matches, and the nonsymbolic one, too | 14:01 |
| mvo | pitti: thanks, I try to reproduce | 14:01 |
| kwwii | pitti: I have an update for the human-icon-theme (adding a 16x16 logout icon to fix a bug), seb128 mentioned that we might be able to include it in intrepid...do you think that is still possible? | 14:02 |
| pitti | kwwii: yes, if it's a nonitrusive change and we'll upload it really really quickly | 14:02 |
| pitti | mvo: http://bazaar.launchpad.net/~ubuntu-core-dev/update-notifier/ubuntu/revision/387 -> TBH I'd just drop the "getlogin()" bit; it might return NULL, and I don't think we should ever start u-n for any system user | 14:04 |
| liw | in 285748 the bug submitter talks about locked or pinned packages in synaptic, but I don't see a way to do that kind of thing, what am I missing? | 14:06 |
| liw | oh, "Lock" is in the "Package" menu, not in the popup menu | 14:07 |
| liw | that locking is probably the same as "hold" in dpkg | 14:08 |
| tkamppeter | pitti, according to the mail notifications I got you have only uploaded foomatic-db but not accepted it into Intrepid. Can you do so? Thanks. | 14:09 |
| pitti | tkamppeter: done some five minutes ago | 14:10 |
| kwwii | tedg: do you know the bug number for the logout icon getting cut-off? | 14:10 |
| mvo | pitti: ok, fine with me | 14:11 |
| pitti | mvo: NB, I'm by no means sure that this is the reason for the crash | 14:12 |
| mvo | pitti: updated in bzr, it check it out | 14:13 |
| mvo | pitti: I mean, I check if i can reproduce the crash | 14:13 |
| kwwii | tedg: nevermind, I found it in my email | 14:13 |
| tedg | kwwii: Heh, I found it too. | 14:15 |
| liw | mvo, is markedKeep in python-apt the same as hold in dpkg? | 14:15 |
| tedg | pitti: Thanks for sponsoring the FUSA upload. | 14:16 |
| ogra | tedg, fyi, all chnges of the recent upload work fine in ltsp, no regressions | 14:16 |
| cjwatson | python-apt markedKeep means "this package isn't going to be changed" | 14:16 |
| mvo | liw: no, that is just for the session | 14:16 |
| mvo | liw: its not persistant | 14:17 |
| cjwatson | in other words to undo a markInstall you do a markKeep | 14:17 |
| cjwatson | (e.g.) | 14:17 |
| mvo | liw: there is nothing in python-apt (at this point) to set the old status | 14:17 |
| mvo | (unfortuantely) | 14:17 |
| liw | mvo, cjwatson: I'm still grepping the synaptic sources to find out for myself, but do you know off-hand what the "lock" thin in the Package menu does? hold in dpkg? | 14:18 |
| mvo | liw: it modifes the apt preferences in /var/lib/synaptic/preferences | 14:18 |
| tedg | ogra: Great! We've now dashed people's hopes that they could do any of those system management things ;) | 14:18 |
| mvo | liw: its a bit of a old wart | 14:18 |
| ogra | :) | 14:18 |
| liw | mvo, interesting, I don't have that file :) | 14:19 |
| mvo | liw: I think the right answer is add support dpkg hold into python-apt, synaptic | 14:19 |
| liw | mvo, is there currently a way to query the synaptic lock setting from outside synaptic? | 14:19 |
| mvo | liw: did you actually put anything on hold? | 14:19 |
| mvo | liw: yes, give me a sec | 14:20 |
| liw | mvo, good point, I didn't | 14:20 |
| liw | now I see it | 14:20 |
| Koon | kwwii: about the FUSA icon bug, apparently if you switch to a theme that uses default gnome icons, it uses a 16x16 greenman icon. Maybe we are just missing a 16x16 shutdown button ? | 14:20 |
| mvo | liw: cache._depcache.ReadPinFile("/var/lib/synaptic/preferences") | 14:21 |
| mvo | liw: fixing that for jaunty would be really cool | 14:21 |
| Koon | (though 16x16 is a little small) | 14:21 |
| tkamppeter | pitti, thanks | 14:22 |
| liw | mvo, ack for jaunty; but I'll use that in intrepid in the time being, thanks | 14:22 |
| kwwii | Koon: yes, I added a 16x16 icon the new theme package | 14:22 |
| Koon | kwwii: great :) | 14:22 |
| mvo | liw: in __init__ somewhere I think its somewhat expensive | 14:22 |
| mvo | Koon: have you seen the fix for the screensaver issue? did you had a chance to test it? | 14:23 |
| kwwii | the reason for that is that before it was shown at 22x22 and now it is in the system tray which has padding to it and uses 16x16 icons (which we did not have before) | 14:23 |
| Koon | mvo: yes, tested ok, and commented on the bug | 14:23 |
| Koon | mvo: looks cleaner than the un-undirect hack. | 14:23 |
| mathiaz | slangasek: I'd like to upload a new landscape-client package to fix bug 285030. Do you have any issue against it? | 14:24 |
| ubottu | Launchpad bug 285030 in landscape-client "private-pre-intrepid to intrepid upgrade of landscape-client -> landscape-{common,client} fails with file ownership conflict" [Undecided,New] https://launchpad.net/bugs/285030 | 14:24 |
| mvo | Koon: yeah, I think its the right fix, however it make me a bit nevous to change dix/window.c one week before release | 14:24 |
| tedg | Okay, so I have a weird bug. It seems like Nautilus starts, but doesn't draw the background or any windows. Even clicking on places won't open a window. Kill Nautilus doesn't help. I can't find any error messages. Anyone know where I could look for debug info? Starting from the command line does literally nothing. | 14:25 |
| Koon | mvo: the proper fix is to disable screensavers entirely, the whole concept is flawed in those years of greenhouse effect chasing. | 14:25 |
| * wgrant is disappointed that the translucent panel background isn't configured on upgrade. | 14:26 | |
| Koon | we could make a gesture for the planet and get rid of a few hundred bugs :) | 14:26 |
| liw | Koon, I'm in favor of removing screensavers entirely (at least from the default install) :) | 14:26 |
| === veloc1ty_ is now known as veloc1ty | ||
| mvo | Koon: I like that! | 14:27 |
| kwwii | wgrant: there is a good reason for not putting the panel background in the theme itself: that causes bugs (the about window then uses the panel bg tiled) | 14:27 |
| tjaalton | mvo: maybe posting to xorg@l.fd.o would attract the right people? | 14:27 |
| Koon | liw, mvo: the idea is to make it look like a political statement rather than a lazy workaround :) | 14:27 |
| wgrant | kwwii: But it makes it look so much better... I only noticed it when I was testing the guest session functionality. | 14:28 |
| mvo | tjaalton: yeah, I will do that next, I was hoping for feedback on #xorg-devel first | 14:28 |
| mvo | Koon: lol | 14:28 |
| tjaalton | mvo: yep, maybe wrong timezone for that ;) | 14:28 |
| kwwii | wgrant: glad to hear you like it :-) | 14:29 |
| kwwii | wgrant: if you set it by hand be sure to open gconf-editor and add the stretch functionality | 14:29 |
| wgrant | kwwii: I just reset my panel config. | 14:29 |
| wgrant | Getting rid of that flat grey is excellent. | 14:30 |
| * Koon tries | 14:30 | |
| didrocks | pitti: thanks :) | 14:31 |
| pitti | didrocks: thanks to you! | 14:31 |
| didrocks | pitti: I will upload an SRU next week :) | 14:31 |
| didrocks | for hardy | 14:31 |
| jdong | whoa, since when did we have CONFIG_EXT4DEV? | 14:35 |
| liw | cjwatson, mvo, do you think it'd be appropriate for system-cleaner to purge packages instead of just removing them? I'm a bit afraid that it would remove important config files too easily, but it does leave some cruft | 14:37 |
| cjwatson | liw: perhaps in jaunty; I don't think we need to worry about it for intrepid | 14:38 |
| liw | cjwatson, ack, at least that gives us time to think about it | 14:38 |
| cjwatson | liw: I agree it's cruft but it usually isn't terribly large in terms of disk space | 14:38 |
| cjwatson | and you would want (for example) to have it list already-removed-but-not-purged items as cruft | 14:39 |
| liw | yup | 14:39 |
| liw | but I don't want it to remove a package and then show it up as cruft _again_, since it has config files remaining | 14:39 |
| persia | Koon, When dropping screensavers, can we only drop them by default? I still have some monitors that expect that sort of treatment (unless you provide non-DPMS blanking another way) | 14:40 |
| wgrant | persia: Is a standard blank screen screensaver not good enough? | 14:42 |
| Koon | kwwii: yes, the panel background looks great. The workspace selector and the windows list seem to be one pixel too big though (or did I miss something when I switched it on ?) | 14:42 |
| persia | wgrant, The standard black screensaver is fine. I thought the idea was to drop the entire screensaver infrastructure in preference to DPMS. | 14:43 |
| persia | (just dim the screen, and then shut off when not in use) | 14:43 |
| kwwii | Koon: to be honest I think it has more to do with the panel screwing up the sizes than anything else...at times I get icons and stuff which is too big, then I log out and back in and they are normal size | 14:44 |
| Koon | kwwii: ok, will try that out :) | 14:44 |
| wgrant | persia: It would have to be able to be blanked for screen locking to be effective. | 14:44 |
| persia | wgrant, Well, only if you rely on authentication mechanisms that benefit from visual feedback. | 14:46 |
| cjwatson | liw: yes - still, post-intrepid I think | 14:46 |
| wgrant | I think my main gripe with the default theme is now the unlock dialog. | 14:48 |
| wgrant | gksu's Compiz one looks very nice. | 14:48 |
| Keybuk | mdz: rfkill0/state doesn't change with the kill switch for me either | 14:48 |
| === lamont` is now known as lamont | ||
| superm1 | slangasek, I'm pretty confident that single library (libAMDXvBA.so.1*) will be able to be split into it's own multiverse package. I'll be splitting it up todayish so hopefully that can be cleaned up | 14:51 |
| mdz | Keybuk: does it depend on the state of the kill switch when the module is loaded (see bug 193970) | 14:53 |
| ubottu | Launchpad bug 193970 in linux-ubuntu-modules-2.6.24 "iwl3945 | iwl4965: Wireless can't be activated after disabling kill switch" [Undecided,New] https://launchpad.net/bugs/193970 | 14:53 |
| Keybuk | mdz: yes, just added a confirmed to that bug | 14:53 |
| james_w | Is anyone willing to review http://paste.ubuntu.com/60125/ for me? | 15:06 |
| james_w | the SIGSEGV I was getting this morning was using freed memory, I had to re-jig quite a bit to stop that happening. | 15:07 |
| mvo | Mirv: I can not reproduce the bug #286363 - can you and if so, how? | 15:08 |
| ubottu | Launchpad bug 286363 in gnome-app-install "app install translations trigger an annoying bug" [Medium,Triaged] https://launchpad.net/bugs/286363 | 15:08 |
| mvo | Mirv: I htink I know what causes it, but I would like to be able to verify | 15:08 |
| mvo | Mirv: nevermind, I can now | 15:10 |
| cjwatson | Riddell: I just noticed that Qt has a segfault handler; do you know if it properly re-raises the segfault so that it's visible by apport? | 15:13 |
| Riddell | cjwatson: it does? where? | 15:14 |
| cjwatson | Riddell: src/corelib/kernel/qcrashhandler.cpp | 15:15 |
| Riddell | cjwatson: if I kill -SEGV a Qt app it gets an apport report in /var/crash | 15:16 |
| cjwatson | ok, good | 15:16 |
| cjwatson | I just asked due to a bug report in which I saw a log message from that function | 15:16 |
| cjwatson | so wasn't sure if the reporter could expect to find a dump in /var/crash | 15:16 |
| tjaalton | mvo: ajax read the patch, and while he thinks it should be higher in the server it looks ok and should work | 15:19 |
| tjaalton | mvo: well, it has been proven to work already.. | 15:20 |
| === dholbach_ is now known as dholbach | ||
| === robbie1 is now known as robbiew | ||
| kwwii | pitti: if case you hadn't noticed I sent the source package url's in an email | 15:21 |
| pitti | kwwii: I'm just processing them | 15:21 |
| mvo | tjaalton: thanks, just read it. ok, that sounds good, do you plan a upload soon? or should I do it? | 15:21 |
| kwwii | pitti: killer, thanks so much (sorry for wasting your time this late in the cycle) | 15:22 |
| tjaalton | mvo: well, if you can think of a version number to use, then sure I can upload :) | 15:22 |
| pitti | kwwii: it's not "wasting" :), no problem | 15:22 |
| tjaalton | mvo: because we now have -2build1, and -2 is unreleased | 15:22 |
| pitti | kwwii: both uploaded (too lazy to reply to mail) | 15:22 |
| wgrant | tjaalton: -2ubuntu1 is all we can do... | 15:23 |
| tjaalton | wgrant: yeah, probably | 15:23 |
| mvo | tjaalton: do you build from git? should I branch from your repo? | 15:24 |
| pitti | mvo: u-n upload> oh, you could reproduce the crash, and it was indeed the getlogin() == NULL issue? | 15:24 |
| tjaalton | mvo: git, no need to branch? | 15:24 |
| tjaalton | mvo: but I can add the patch there, it's trivial | 15:25 |
| mvo | tjaalton: meh, my git foo is *so* weak :) if you don't hdate if when I upload it and just give you a debdiff, that would be me a happier man (or you just commit it ) | 15:25 |
| tjaalton | mvo: heh, yeah I'll do it | 15:26 |
| tjaalton | I guess the patch for bug 261977 can go in as well | 15:26 |
| ubottu | Launchpad bug 261977 in dell "nv is chosen even if it doesn't support the card" [Undecided,Confirmed] https://launchpad.net/bugs/261977 | 15:26 |
| * pitti hugs james_w for his consolekit debugging | 15:28 | |
| james_w | hey pitti, I hope I got it this time | 15:29 |
| mvo | thanks tjaalton! | 15:30 |
| liw | kwwii, there's a volunteer making an icon for system-cleaner, and he's asking me questions I don't know about; could you give 274714 a quick peek? | 15:30 |
| kwwii | liw: sure | 15:34 |
| kwwii | liw: btw, I started an icon for that but never got very far, sorry | 15:34 |
| Koon | ogra: please comment on https://bugs.launchpad.net/ubuntu/+source/dhcp3/+bug/280123/comments/3 | 15:35 |
| ubottu | Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/280123/+text) | 15:35 |
| Koon | ouch. | 15:35 |
| ogra | Koon, on my way | 15:35 |
| liw | kwwii, no worries, I don't think an icon is necessary, merely nice | 15:35 |
| liw | kwwii, a really good dark theme is important, on the other hand, thanks for that ;-) | 15:36 |
| Koon | ogra: basically, I find dhcp3-server too dumb to react correctly to an interface addition | 15:36 |
| ogra | Koon, i'm fine to go with what we have now for intrepid ... all i was worried about was that NM would break ltsp installs which doesnt seem to be the case, but i thik we shoud revisit it for jaunty and sanitize it a bit | 15:37 |
| Koon | ogra: ok, will untarget 8.10 then, and keep it on the radar | 15:37 |
| ogra | Koon, we should robably even consider to port dhcpd over to upstart and solve the probs one and for all in jaunty (if Keybuk manages to get upstart ready for us though :) ) | 15:38 |
| Keybuk | ? | 15:39 |
| Keybuk | why would that be ported to upstart? | 15:39 |
| ogra | Keybuk, dont we want all initscripts replaced with upstart events at some point ? | 15:40 |
| kwwii | erm huh??? "Sorry, there was a problem connecting to the Launchpad server." | 15:42 |
| Keybuk | one day | 15:42 |
| Keybuk | no rush there | 15:43 |
| kwwii | liw: I wrote a big nice comment but it seems the server keeps timing out | 15:43 |
| * cjwatson takes a deep breath and dives into component-mismatches.txt | 15:43 | |
| liw | kwwii, oh dear | 15:43 |
| liw | kwwii, at the same time my X crashed, this must be connected... :) | 15:43 |
| ogra | Keybuk, no, but there is no point to fiddle with workarounds in sysvinit script over and over if we know we can fix it the right way :) | 15:43 |
| kwwii | lol, no doubt | 15:43 |
| davmor2 | tseliot: ping | 15:54 |
| tseliot | davmor2: yes? | 15:55 |
| davmor2 | you're working on jockey is that correct? | 15:55 |
| slangasek | mathiaz: 285030> go ahead | 15:56 |
| tseliot | davmor2: yes | 15:56 |
| slangasek | superm1: hmmm, if that lib can be split into its own package completely, then what even uses it? Should we just not bother shipping it? | 15:57 |
| superm1 | slangasek, it's used by the driver "if" you attempt to use their accelerated mpeg2 playback | 15:58 |
| davmor2 | tseliot: is there a reason for the delay in the progress bar when installing a driver? There seems to be a quick flash and then nothing till about 52% | 15:58 |
| slangasek | superm1: ah | 15:58 |
| superm1 | slangasek, by using XvMC in mplayer or similar | 15:58 |
| tseliot | davmor2: you might want to ask pitti about this | 15:58 |
| davmor2 | pitti: ^ | 15:59 |
| persia | pitti, I did some more testing, and investigation about HAL and joysticks. It seems that on amd64 10-x11-input.fdi is successfully mapping info.capabilities including input.mouse to input.x11_driver evdev, but that despite the same content of the files for i386, this doesn't work, which by chance makes joysticks work. | 16:01 |
| tkamppeter | pitti, in bug 286080 someone complains that CUPS stops working when he has the resolvconf package (is in universe) installed. Would you fix the AppArmor conf for Intrepid? | 16:10 |
| ubottu | Launchpad bug 286080 in cupsys "cups fails to print to network printer if resolvconf package is installed (apparmor)" [Undecided,New] https://launchpad.net/bugs/286080 | 16:10 |
| liw | kwwii, LP just e-mailed me your comments, thanks! | 16:20 |
| kwwii | liw: hope that helps | 16:20 |
| kwwii | liw: after thinking about it, they might want to use an existing screwdriver (and broom if it also already exists) and just put them together | 16:21 |
| slangasek | tkamppeter: that's not a bug in the cups apparmor policy, it needs to be added to apparmor's nameservice abstraction. | 16:23 |
| tkamppeter | slangasek, so it has to be moved to the apparmor package? | 16:34 |
| slangasek | tkamppeter: already done (with difficulty, LP is being very slow right now) | 16:35 |
| tkamppeter | slangasek, you are sure that apport is providing this part? | 16:36 |
| psusi | does anyone know if there is a a developer mailing list for e2fsprogs? I can't seem to find one... | 16:37 |
| slangasek | tkamppeter: yes... | 16:37 |
| cjwatson | ogra: do we want xserver-xorg-video-amd in main? | 16:45 |
| cjwatson | I see that hardy had -geode so my guess is no | 16:45 |
| ogra | cjwatson, i dont think so, geode should replace it anyway already | 16:45 |
| ogra | its a transitional package afaik | 16:46 |
| cjwatson | done, with any luck | 16:46 |
| sbeattie | is denemo moving to universe? | 16:53 |
| slangasek | ArneGoetje, pitti: there seem to be some language-pack-foo-base packages missing, that leave us with uninstallables: arn, bra, pap, syr | 16:56 |
| mdz | cjwatson: http://people.ubuntu.com/~mdz/temp/Screenshot-QEMU.png | 16:59 |
| pitti | davmor2: progress bar> python-apt doesn't give me anything better :( | 16:59 |
| persia | pitti, The other alternative is to use synaptic as a backend, which gives a slightly nicer progress bar (update-manager does this by default) | 17:00 |
| persia | Just set everything up with python-apt, and then call synaptic to apply the changes. | 17:01 |
| davmor2 | pitti: I just wondered as it looks to all intents like it is doing nothing I always check my hd lights by default on any progress bars due to issues with d-i so that was the only reason I knew it was doing stuff :) | 17:01 |
| mvo | davmor2: what is the problem with the progress bar? | 17:03 |
| davmor2 | mvo: you get a quick flash of brown and then nothing till 52% so it just looks like it has stalled. | 17:04 |
| mvo | davmor2: on what operation? | 17:04 |
| davmor2 | mvo: installing nvidia driver from jockey | 17:04 |
| mvo | davmor2: oh, right. I think/guess the issue is the dkms compilation | 17:05 |
| davmor2 | mvo: it stay's on 0% until it hits 52% and then works as expected. | 17:06 |
| tseliot | pitti: does the download of packages increment the progress bar in jockey? | 17:07 |
| pitti | tseliot: only in very coarse steps unfortunately | 17:07 |
| pitti | I think it's doing the entire unpack/configure step in one big chunk | 17:07 |
| cjwatson | mdz: just jigdoing down the CD now | 17:08 |
| calc | grr launchpad seems to keep timing out on me :( | 17:08 |
| pitti | download is a little better AFAIR | 17:08 |
| pitti | persia: synaptic> right, I just need to find a way to integrate that in an upstream friendly manner | 17:08 |
| persia | calc, There's been a lot of that in the last few hours. LP devs are chasing. | 17:08 |
| persia | pitti, Yeah, that's the less easy bit. | 17:09 |
| persia | Maybe try synaptic, and fall back to python-apt if it isn't available? | 17:09 |
| cjwatson | lool/persia: does mobile need wireless-tools/wpasupplicant? this is regarding bug 61618 | 17:10 |
| ubottu | Launchpad bug 61618 in ubuntu-meta "wireless-tools,wpasupplicant in -minimal" [Wishlist,Fix released] https://launchpad.net/bugs/61618 | 17:10 |
| persia | cjwatson, Does NM need those? If so, yes. | 17:11 |
| persia | cjwatson, MID too. | 17:12 |
| persia | Mobile will get them from desktop-common | 17:12 |
| cjwatson | network-manager depends on wpasupplicant, but not wireless-tools | 17:12 |
| cjwatson | it's perhaps best to add that anyway just to reduce risk | 17:13 |
| geser | zul: have you some time to look at the debdiff at http://paste.ubuntu.com/60169/ for bug #286450? | 17:13 |
| ubottu | Launchpad bug 286450 in xen-3.3 "libxen3 and libxen3-dev have bogus Replaces: versions" [Undecided,New] https://launchpad.net/bugs/286450 | 17:13 |
| cjwatson | dendrobates: do you want to have wireless and WPA support installed by default on servers, or is it OK for people to have to install packages to get it? | 17:14 |
| dendrobates | cjwatson: We have always installed by default previously, correct? | 17:15 |
| cjwatson | yes | 17:15 |
| mdz | cjwatson: the one I tested was actually 20081013 | 17:15 |
| mdz | I'm rsyncing the latest now | 17:16 |
| cjwatson | dendrobates: having it in minimal is awkward for various reasons but we could put it in the server seed (rather than server-ship) if you want to keep it | 17:16 |
| dendrobates | cjwatson: I would not want to change that at htis stage then. We can look at making it optional for 9.04 | 17:16 |
| pitti | persia: calling synaptic directly doesn't work, since the install is done in the d-bus backend (no $DISPLAY, root user) | 17:17 |
| cjwatson | dendrobates: ok, I'll move it to server | 17:17 |
| persia | pitti, Ah, in that case, yeah, you need python-apt. | 17:17 |
| pitti | persia: so providing this kind of "backend does callback to GUI which then runs synaptic as root" is incredibly hairy, and the reason why I didn't do it in the first place | 17:18 |
| persia | "incredibly hairy" is an understatement :) | 17:18 |
| pitti | persia: I actually want to use packagekit in a future version, BTW | 17:18 |
| pitti | anyway, dinner time | 17:18 |
| dendrobates | cjwatson: cjwatson: ta | 17:20 |
| cjwatson | dendrobates: (the practical difference here is that it makes it easier for people to remove) | 17:21 |
| cjwatson | ArneGoetje: are you still working on the remaining needs-review .pot files? | 17:23 |
| cjwatson | ArneGoetje: the five most recent are actually important | 17:24 |
| zul | geser: maybe this afternoon or later tonight | 17:30 |
| doko | anybody here who could test the cacao-oj6-plugin on powerpc? | 17:37 |
| * calc kicks lp | 17:40 | |
| * calc is trying to do bug triage but no access to lp is hampering that | 17:40 | |
| persia | doko, If nobody answers, you might ask in #ubuntu-powerpc, although it's not always very active. | 17:41 |
| slangasek | ogra: oh, it looks like rasmol can be demoted now, that's a much easier solution | 17:41 |
| mdz | cjwatson: <kirkland> mdz: dendrobates: i am able to reproduce the problem | 17:43 |
| cjwatson | I'm part-way through a test install now | 17:43 |
| cjwatson | kirkland: ^- | 17:44 |
| kirkland | cjwatson: the grub menu.lst has root=/dev/dm-0 | 17:44 |
| cjwatson | grub is not supposed to be used for LVM installs. | 17:44 |
| kirkland | cjwatson: hmm, really? my desktop is grub+lvm+encryption | 17:45 |
| Chipzz | cjwatson: so is my server | 17:45 |
| cjwatson | if lvdisplay "$bootfs" | grep -q 'LV Name' 2>/dev/null || [ -e "$(dirname $bootfs)/control" ]; then | 17:45 |
| Chipzz | (same as kirkland) | 17:45 |
| cjwatson | if ! is_sataraid $bootfs && ! is_multipath $bootfs; then | 17:45 |
| cjwatson | log "/boot is a lvm volume ($bootfs), cannot install grub" | 17:45 |
| cjwatson | exit 1 | 17:45 |
| cjwatson | fi | 17:45 |
| cjwatson | fi | 17:46 |
| cjwatson | grub-installer/debian/isinstallable | 17:46 |
| Chipzz | ah ok, I have a seperate /boot which is not on LVM | 17:46 |
| cjwatson | oh, I suppose partman-auto-lvm sets up a plain /boot | 17:46 |
| cjwatson | ok | 17:46 |
| kirkland | cjwatson: ah, okay | 17:46 |
| cjwatson | never mind then, that's a red herring | 17:46 |
| cjwatson | I'll work on this | 17:46 |
| kirkland | cjwatson: well, i'm arguing that root=/dev/dm-0 is not correct, on an lvm setup | 17:47 |
| kirkland | cjwatson: it should be root=/dev/mapper/vg0-lv0 or some such | 17:47 |
| cjwatson | it should be /dev/mapper/ubuntu-root shouldn't it? | 17:47 |
| cjwatson | give me a minute to reproduce this far enough that I can discuss it intelligently | 17:47 |
| kirkland | cjwatson: /me on standby | 17:48 |
| cjwatson | the UUID stuff in grub has the standard set of guards around it for LVM, RAID, etc. | 17:49 |
| cjwatson | it looks like it has functioned as a canary regarding the /dev/dm-0 breakage | 17:50 |
| slangasek | hrm, would this be related to the change to not munge device names to uuids in update-grub? | 17:50 |
| slangasek | /dev/dm-* wasn't one of the options excluded by convert_kopt_to_uuid() previously, so update-grub would replace that with the UUID when it saw it | 17:52 |
| cjwatson | kirkland: did you reproduce this with encryption or without | 17:52 |
| cjwatson | /dev/dm-* is wrong anyway | 17:52 |
| kirkland | cjwatson: without | 17:52 |
| cjwatson | we shouldn't be using enumerated names when there are perfectly good fixed ones | 17:52 |
| slangasek | yes, it's wrong, just wondering if this is what exposed the problem | 17:52 |
| kirkland | cjwatson: that's on today's amd64 server iso, 763148b72316ab202b4df2a8373708f1 | 17:53 |
| cjwatson | it's possible; note this is different from the UUID change that mdz is probably thinking of :) | 17:53 |
| mdz | cjwatson: my install ended up using UUID for the GRUB root device but not for the kernel root device | 17:55 |
| calc | anyone happen to remember the url to see the full top 100 bug stats on LP? | 17:56 |
| calc | i seem to have lost the bookmark to that | 17:56 |
| mdz | cjwatson: I couldn't tell which one was causing the failure though | 17:56 |
| cjwatson | mdz: likely the former, but the latter is a problem too (using /dev/dm-0) | 17:56 |
| cjwatson | fixing the latter will make the former stop happening | 17:56 |
| cjwatson | because /dev/mapper/* is excluded from UUID handling, as is usual | 17:56 |
| cjwatson | I wonder if /target/dev has been unmounted or something | 17:57 |
| kirkland | mdz: what did your kernel line have root=? | 17:58 |
| mdz | cjwatson: anything i can do to help? I hadn't opened a bug yet but can do so | 17:58 |
| mathiaz | kirkland: where you also prompted for activating serial ATA RAID configuration when doing you test install in kvm? | 17:58 |
| mdz | kirkland: http://people.ubuntu.com/~mdz/temp/Screenshot-QEMU.png | 17:58 |
| kirkland | mathiaz: no | 17:58 |
| cjwatson | mdz: give me five minutes, please | 17:58 |
| kirkland | mdz: yup, same as mine | 17:58 |
| kirkland | well, different UUID (thankfully) | 17:59 |
| slangasek | cjwatson: bugger, there's definitely a bug in my grub change, I assumed grub-install was setting the root device to the UUID on install and it's apparently relying on update-grub to do this | 17:59 |
| mathiaz | kirkland: hm - ok. | 18:00 |
| cjwatson | mathiaz: that only happens if you have dmraid metadata on your disks | 18:01 |
| slangasek | cjwatson: though I have root on LVM and when I installed, root was correctly pointed to /dev/mapper, so that doesn't fully explain this behavior | 18:01 |
| cjwatson | mdz: I can reproduce the problem so should not need further information | 18:02 |
| mathiaz | cjwatson: well - this a kvm install with standard qcow2 images | 18:02 |
| ScottK | slangasek and cjwatson: It looks like ubuntu-policy was promoted to Main without the normal review and it now dep-waits on a build-dep in Universe (pstoedit). At this point would it be better just to demote it so mdz's upload will build? | 18:02 |
| cjwatson | mathiaz: so is mine, and I don't see this | 18:02 |
| cjwatson | I'm ok with demoting ubuntu-policy | 18:02 |
| slangasek | ack, demoting it | 18:03 |
| mathiaz | cjwatson: are you using virtio block devices? | 18:03 |
| mathiaz | kirkland: ^^? | 18:03 |
| ScottK | Wahoo. One off the out-of-date list then. | 18:03 |
| cjwatson | mathiaz: no | 18:03 |
| kirkland | mathiaz: looks like slangasek nailed the problem | 18:03 |
| cjwatson | kirkland: uh, I think these are two orthogonal problems | 18:04 |
| cjwatson | one is exposing the other | 18:04 |
| slangasek | kirkland: except not all of it, I don't know why /dev/dm-0 would be chosen as the name for the rootfs in the first place | 18:04 |
| kirkland | slangasek: ah, okay | 18:04 |
| slangasek | does someone have / on a plain disk partition, that they could test for me? | 18:04 |
| === thegodfather is now known as fabbione | ||
| kirkland | slangasek: yup | 18:08 |
| kirkland | slangasek: what do you need? | 18:08 |
| slangasek | kirkland: mv /boot/grub/menu.lst{,.saveme}; update-grub -y; diff -u /boot/grub/menu.lst{.saveme,} | 18:08 |
| cjwatson | ah, /dev/dm-0 is coming from findfs | 18:09 |
| slangasek | kirkland: and post me the results - I'm pretty sure you're going to have root=/dev/fiddlefaddle1 instead of root=UUID=nomnom | 18:09 |
| kirkland | slangasek: okay, i'm updating the vm to current intrepid now | 18:09 |
| slangasek | kirkland: (and once you have the diff, you can restore the original menu.lst) | 18:10 |
| kirkland | slangasek: ;-) | 18:10 |
| Mirv | mvo: thanks, works great! wouldn't have guessed pyxdg as the culprit. | 18:10 |
| mvo | Mirv: thanks a lot for finding the problem itself, fixing it was relatively painless | 18:10 |
| * mvo hugs Mirv | 18:10 | |
| mathiaz | kirkland: hm. Could you confirm that you're using ide block device rather than virtio block device? It's probably irrelevant to the bug discussed above - but I may have found another one. | 18:10 |
| kirkland | mathiaz: i am not using virtio at the moment in my testing of the current problem | 18:11 |
| mathiaz | kirkland: ok. Thanks. | 18:11 |
| mathiaz | kirkland: so virtio block devices are detetected as having dmraid data | 18:11 |
| * cjwatson will get back to this after dinner | 18:12 | |
| kirkland | mathiaz: hmm, how so? | 18:12 |
| kirkland | mathiaz: that might actually be related to cjwatson's finding that findfs() is pointing at /dev/dm-0 | 18:12 |
| mathiaz | kirkland: I don't know. If I boot a vm with a virtio block device I get a message stating that Serial ATA Raid devices have been found | 18:13 |
| cjwatson | findfs the binary, not findfs the function | 18:13 |
| cjwatson | as in e2fsprogs | 18:13 |
| kirkland | cjwatson: erg, /me was looking at the wrong code then | 18:13 |
| cjwatson | virtio/dmraid> nothing whatsoever to do with findfs, that's in hw-detect | 18:13 |
| cjwatson | anyway, will look after dinner | 18:13 |
| mathiaz | cjwatson: ok. I'll file a bug against hw-detect then | 18:13 |
| psusi | does anyone know if there is a a developer mailing list for e2fsprogs? I can't seem to find one... | 18:13 |
| mathiaz | kirkland: if I boot a vm with an ide block device that message doesn't appear. | 18:14 |
| kirkland | mathiaz: the _same_ vm? | 18:15 |
| mathiaz | kirkland: yes | 18:15 |
| mathiaz | kirkland: just changing the configuration in libvirt and I've got the Serial ATA Hardware RAID message printed during the install (in case the vm is started with virtio block devices) | 18:16 |
| psusi | mathiaz: are you running the vm with a virtual disk image you took from a real hard disk? | 18:20 |
| psusi | and if so, was that real hard disk ever part of a sata raid set? | 18:20 |
| mathiaz | psusi: nope - it's a qcow2 image file created with qemu-create | 18:20 |
| mathiaz | psusi: or qemu-img rather | 18:21 |
| psusi | hrm... interesting... can you run dmraid -r in the vm and see if it says it sees raid devices? | 18:22 |
| kirkland | slangasek: http://pastebin.com/f52871f2b | 18:25 |
| kirkland | slangasek: (sorry for the delay--distracted) | 18:25 |
| slangasek | kirkland: no problem - I'm still fighting with update-grub to get a proper minimal fix | 18:25 |
| mathiaz | psusi: dmraid -r states that no block devices found | 18:28 |
| mathiaz | psusi: I ran the command above just after the message was printed in the installer | 18:28 |
| psusi | hrm.... strange... | 18:29 |
| tseliot | slangasek: what do you think about these changes to the nvidia section of release notes? http://pastebin.com/m7d083dfa | 18:29 |
| tseliot | slangasek: I have warned mvo against this, therefore Update Manager will deal with the SSE problem too | 18:30 |
| slangasek | tseliot: hands full at the moment, sorry; I'm aware of the SSE issue and have already approved mvo's upload to address this in update-manager, I agree we should comment it in the release notes but have no time to review specific text at the moment | 18:32 |
| tseliot | slangasek: ok, no problem | 18:32 |
| cjwatson | psusi,mathiaz: hw-detect uses dmraid -c -s | 18:32 |
| cjwatson | mathiaz: what does that print? | 18:32 |
| mathiaz | cjwatson: same message: no devices found | 18:33 |
| cjwatson | mathiaz: is that absolutely literal? capitalisation, etc.? | 18:33 |
| mathiaz | cjwatson: same message: no *block* devices found | 18:33 |
| doko | lool, seb128: I don't want to have pyopengl in main. can we make it a suggests in gnome-games instead? | 18:33 |
| slangasek | kirkland: can you pull from lp:~ubuntu-core-dev/grub/ubuntu, build a package, and test? the kopt diff should disappear now | 18:33 |
| cjwatson | mathiaz: I need the precise text | 18:33 |
| kirkland | slangasek: k | 18:33 |
| mathiaz | cjwatson: "no block devices found" | 18:34 |
| cjwatson | interesting, hw-detect tests against "No RAID disks" | 18:34 |
| cjwatson | TheMuso: ^- | 18:34 |
| pitti | lool: can we talk about sorting out elisa dependencies tomorrow morning? (sorry, need to leave now) | 18:34 |
| kirkland | slangasek: Branched 863 revision(s) .... correct? :-) | 18:35 |
| slangasek | kirkland: yes | 18:35 |
| kirkland | slangasek: okay, done | 18:38 |
| kirkland | slangasek: menu.lst is back to what it was before | 18:38 |
| slangasek | kirkland: ok, thanks | 18:38 |
| kirkland | slangasek: thank *you* :-) | 18:39 |
| slangasek | cjwatson: grub 0.97-29ubuntu44 uploaded, kirkland has confirmed that root=UUID= is being set correctly again on initial menu.lst creation; can you review? | 18:41 |
| slangasek | or should I let you fight with the installer and unblock it myself? | 18:41 |
| kirkland | pitti: ping | 18:44 |
| kirkland | pitti: regarding bug #284443, i'm not going to fix that in ecryptfs-utils; i added a task a task for you guys to decide if it merits a note in the gdmsetup interface | 18:45 |
| ubottu | Launchpad bug 284443 in gdm "ecryptfs does not work with gdm auto-login" [Undecided,New] https://launchpad.net/bugs/284443 | 18:45 |
| doko | kees, bryce: does inkscape need python-uniconvertor? | 18:51 |
| cjwatson | slangasek: that grub change makes sense to me | 18:52 |
| cjwatson | slangasek: accepted | 18:52 |
| slangasek | thanks | 18:53 |
| slangasek | (and sorry) | 18:53 |
| cjwatson | I'll see if I can do something about the /dev/dm-0 thing, although I can't decide whether that's release-critical | 18:53 |
| Mirv | mvo: heh, no problem. I've reported some other gai bugs as well but they are quite minor in comparison. possibly bug #283950 since without fixing it one cannot install free java plugin via gai. | 18:53 |
| ubottu | Launchpad bug 283950 in gnome-app-install "[intrepid] Replace icedtea-gcjwebplugin with icedtea6-plugin in gnome-app-install" [Undecided,New] https://launchpad.net/bugs/283950 | 18:54 |
| Mirv | maybe that's icedtea6-plugin bug also, perhaps it shouldn't conflict with the transitional package since that doesn't make the transitional package very functional | 18:55 |
| === ssweeny is now known as scolbert | ||
| === scolbert is now known as ssweeny | ||
| slangasek | cjwatson: I guess that depends on the reasons for not converting /dev/mapper/* to UUID, since those probably also apply to /dev/dm-* | 18:56 |
| slangasek | i.e., /dev/dm-* is wrong, but UUID= may also be wrong | 18:56 |
| mvo | thanks Mirv | 18:57 |
| cjwatson | slangasek: the reason for not converting /dev/mapper/VG-LV to UUID is that VG-LV already uniquely and reliably identify the device | 18:57 |
| cjwatson | slangasek: I'm not sure whether the same holds for /dev/dm-*, i.e. whether that enumeration is stable | 18:57 |
| slangasek | cjwatson: ok - so it's not a concern that UUID= will be less robust for things like multipath? | 18:58 |
| slangasek | I don't think /dev/dm-* is stable in the general case | 18:58 |
| cjwatson | I'm not entirely certain about multipath, but at least for LVM it's simply that we don't need it | 18:58 |
| cjwatson | the reason findfs shows /dev/dm-* is that that's what shows up in /proc/partitions | 18:58 |
| * slangasek nods | 18:59 | |
| cjwatson | it does have some /dev/mapper/ logic, but it's only as a fallback in case it can't find the primary name | 18:59 |
| cjwatson | or at least what it thinks of as the primary name | 18:59 |
| slangasek | then it doesn't sound like fixing the /dev/dm-* bit is RC | 19:00 |
| cjwatson | I'm wondering if it's better to change e2fsprogs (simpler change, but more risk of unforeseen consequences) or grub (more complicated change, but much more contained) | 19:00 |
| cjwatson | I'd like to know first whether hardy did /dev/dm-* | 19:00 |
| slangasek | well, it didn't for me | 19:00 |
| slangasek | nor did intrepid when I installed it, around alpha-4/5 | 19:00 |
| cjwatson | then it seems to me that there is a risk of regressions here | 19:00 |
| cjwatson | I suspect that this is a recent e2fsprogs change ... | 19:01 |
| slangasek | yes, that's fair | 19:01 |
| ogra | slangasek, hmm, looks like rasmol ftbfs | 19:03 |
| slangasek | ogra: no, it failed to upload | 19:04 |
| slangasek | we'll see if we can clear that up | 19:04 |
| ogra | i got build logs | 19:04 |
| ogra | right, not failures | 19:04 |
| ogra | didnt look close enough | 19:04 |
| ogra | ah, well, hppa failed though | 19:05 |
| slangasek | well, it FTBFS on hppa, but everything does | 19:05 |
| ogra | yeah, ftbfs seems a normal condition for everything on hppa recently | 19:05 |
| slangasek | not everything, just everything that transitively depends on glib2.0 | 19:05 |
| ogra | ah | 19:06 |
| slangasek | so, you know, "Ubuntu" | 19:06 |
| ogra | heh | 19:06 |
| cjwatson | slangasek: I suspect this in e2fsprogs 1.41.1-1: | 19:07 |
| cjwatson | + * Make the blkid library more efficient for devicemapper devices, | 19:07 |
| cjwatson | + mostly by no longer using the libdevmapper library. | 19:07 |
| slangasek | huh | 19:08 |
| slangasek | sounds likely :/ | 19:08 |
| mathiaz | cjwatson: TheMuso: I've filed bug 286538 with my findings about SATA Raid with virtio block devices. | 19:09 |
| ubottu | Launchpad bug 286538 in hw-detect "virtio block devices are detected as SATA RAID devices" [Undecided,New] https://launchpad.net/bugs/286538 | 19:09 |
| cjwatson | mathiaz: I assume this isn't release-critical, it's just an ugly warning, right? | 19:09 |
| cjwatson | mathiaz: oh, err, if you carry on does partitioning work? | 19:10 |
| mathiaz | cjwatson: hm - I don't it's release-critical. Although it's warning message I wonder what happens if the end user selects yes - activate raid arrays. | 19:10 |
| mathiaz | cjwatson: partitionning works as expected. | 19:10 |
| cjwatson | oh, virtio is /dev/vd* isn't it? | 19:11 |
| kirkland | cjwatson: yes | 19:11 |
| mathiaz | cjwatson: correct. | 19:11 |
| siretart | asac: is there something left to do for wpasupplicant in bug #272185? | 19:12 |
| ubottu | Launchpad bug 272185 in network-manager-applet "[Intrepid] iwl3945 + iwl4965 -- network-manager will not connect to a WPA EAP (Enterprise) network (disassociating by local choice (reason=3) )" [High,Fix released] https://launchpad.net/bugs/272185 | 19:12 |
| mathiaz | cjwatson: ok. Nothing breaks even if the end user chooses to activate the RAID arrays. | 19:12 |
| mathiaz | cjwatson: So it's just a warning message that may be disturbing. | 19:13 |
| cjwatson | mathiaz: I bet it's http://paste.ubuntu.com/60209/ | 19:15 |
| mathiaz | cjwatson: seems like a good candidate. Could SATA Raid device name start with a v ? | 19:18 |
| cjwatson | no idea | 19:18 |
| cjwatson | this totally isn't for intrepid | 19:18 |
| mathiaz | cjwatson: agreed. | 19:21 |
| bryce | doko: it's not a hard dependency; it provides some file import/output converters | 19:25 |
| doko | bryce: please either write a MIR, or change it to a suggests for intrepid | 19:25 |
| bryce | doko: I think currently it only provides a few file formats, but going forward I understand it'll be gaining more | 19:26 |
| bryce | hmm, okay will do | 19:26 |
| cjwatson | slangasek: what do you think of http://paste.ubuntu.com/60216/ ? | 19:41 |
| slangasek | cjwatson: excess use of fork :), but looks good | 19:43 |
| lool | doko: I have no strong opinion on opengl in gnome-games | 19:43 |
| lool | pitti: Sure | 19:43 |
| lool | pitti: I talked to upstream, and we want libvisuall-plugins | 19:44 |
| slangasek | (excess use of fork --> stat -c %t:%T, one stat call per device) | 19:44 |
| lool | pitti: So I'll look at promoting it | 19:44 |
| cjwatson | aha, good point | 19:44 |
| doko | lool: ok, if I move to a suggestion? | 19:44 |
| cjwatson | http://paste.ubuntu.com/60218/ then | 19:44 |
| slangasek | if by 'good' you mean 'nitpicky' :-) | 19:45 |
| slangasek | yep, looks good | 19:45 |
| asac | siretart: i dont thinks so. didnt i invalidate the wpasupplicant task yet? | 19:45 |
| lool | doko: Best to check with seb, not enough data on my side | 19:45 |
| doko | lool, will do tomorrow. same for python-gtkglext1 | 19:46 |
| lool | same answer :) | 19:46 |
| asac | siretart: hmm. if it turns out that its still happening then wpasupplicant might be a candidate for this again. | 19:52 |
| === seb128_ is now known as seb128 | ||
| calc | bryce: yea we will have UTC-0800 to UTC+0800 represented in our group | 20:37 |
| bryce | calc, :-/ | 20:38 |
| * calc thinks we should all move to europe ;-) | 20:38 | |
| cjwatson | slangasek: hmm, works fine until I reboot and findfs complains about /dev/dm-* not being present ... | 20:44 |
| slangasek | hmm, findfs gets called after reboot? | 20:44 |
| cjwatson | /etc/init.d/checkroot.sh | 20:45 |
| cjwatson | so it fails to check the root filesystem | 20:45 |
| slangasek | doh | 20:45 |
| cjwatson | I'm wondering if this is a bug in the udev rules shipped in the installer | 20:46 |
| cjwatson | <cjwatson@riva ~>$ dpkg -c /mirror/ubuntu/pool/main/d/devmapper/dmsetup_1.02.27-3ubuntu1_i386.deb | fgrep .rules | 20:48 |
| cjwatson | -rw-r--r-- root/root 1262 2008-08-27 03:17 ./etc/udev/rules.d/65-dmsetup.rules | 20:48 |
| cjwatson | <cjwatson@riva ~>$ dpkg -c /mirror/ubuntu/pool/main/d/devmapper/dmsetup-udeb_1.02.27-3ubuntu1_i386.udeb | fgrep .rules | 20:48 |
| cjwatson | <cjwatson@riva ~>$ | 20:48 |
| cjwatson | is it just me or is that screwy? | 20:48 |
| slangasek | hmm, udev doesn't supply the rules centrally? | 20:53 |
| === robbiew is now known as robbiew-lunch | ||
| cjwatson | slangasek: no, depends on devmapper and mdadm for some of them | 21:05 |
| cjwatson | slangasek: ok, I talked through this on the phone with Keybuk | 21:05 |
| cjwatson | slangasek: we think that the problem is as follows: missing dmsetup-udeb udev rules => /dev/dm-* exists when it shouldn't, and /dev is bind-mounted onto /target/dev => findfs UUID=foo returns /dev/dm-* *and caches it in /etc/blkid.tab which persists across reboots* => findfs in installed system returns the same value | 21:07 |
| cjwatson | slangasek: as far as we can tell, simply restoring the dmsetup-udeb udev rules will fix all the problems at once | 21:07 |
| cjwatson | slangasek: except for the fundamental problem that blkid caches stuff across reboots which is the basic difference between blkid and vol_id, so that'll eventually be fixed by using vol_id everywhere | 21:07 |
| cjwatson | (probably) | 21:07 |
| Keybuk | that findfs is going to bite us in lots of other interesting ways | 21:10 |
| Keybuk | I'm surprised it hasn't been already | 21:10 |
| slangasek | so do we know where the dmsetup udev rules went? | 21:10 |
| cjwatson | lost in a merge from Debian, where waldi did it wrong | 21:12 |
| slangasek | ah | 21:12 |
| slangasek | so on track for recovering them? :) | 21:13 |
| cjwatson | it's a one-liner | 21:13 |
| cjwatson | just need to figure out how to test it | 21:13 |
| cjwatson | Keybuk: does udev inotify-monitor /etc/udev/rules.d | 21:13 |
| cjwatson | ? | 21:13 |
| cjwatson | Keybuk: actually, never mind, the question is moot I think | 21:14 |
| Keybuk | yes | 21:14 |
| Keybuk | ah, I see why that findfs fails in this sense - it overrides UUID=foo to be /dev/dm-0 because that's in the blkid cache | 21:15 |
| Keybuk | which will promptly fail to check, and therefore bail out | 21:15 |
| Keybuk | _but_ if findfs simply returns nothing, it will use /lib/init/rw/rootdev (?! why not /dev/root ?!) instead | 21:15 |
| Keybuk | the other failure mode we tend to see is negative - in that a UUID that vol_id is sure exits, blkid is sure doesn't - so that will fall back to use /lib/init/rw/rootdev | 21:16 |
| Keybuk | there may be a bug where findfs returns a different block device than vol_id for a given uuid - but that's gonna be pretty rare | 21:16 |
| cjwatson | any time devices change between boots and blkid has the old one cached, findfs and vol_id will return different block devices for a given UUID | 21:21 |
| seb128 | slangasek: you don't want to accept the evolution-* updates? earlier is better, especially that upstream is not around next week so if changes are required better now | 21:21 |
| slangasek | seb128: I was still looking at them; people keep piling more fixes in the queue... | 21:21 |
| seb128 | slangasek: right, I noticed that, I was just wondering if that was supposed to be a fifo queue ;-) | 21:22 |
| slangasek | not entirely :) | 21:22 |
| cjwatson | ok, dmsetup-udeb test in progress now | 21:22 |
| seb128 | slangasek: the diff are probably hard to read, the svn snapshot was a patch in the debian directory | 21:22 |
| cjwatson | after typing in the entire rules file by hand | 21:22 |
| slangasek | ah, twitch | 21:22 |
| cjwatson | slangasek: oh, in case it wasn't clear, the udev rules are in dmsetup just fine, it's just that the debian/rules code for copying those into the udeb was wrong | 21:23 |
| slangasek | cjwatson: ah :) | 21:23 |
| slangasek | seb128: is anyone taking care of mail-notification and evolution-jescs, which will also need rebuilds? | 21:37 |
| slangasek | seb128: e-d-s accepted, btw | 21:37 |
| cjwatson | slangasek,Keybuk: bingo | 21:37 |
| seb128 | slangasek: we have active desktop contributors which will do those and I'll do the sponsoring | 21:38 |
| seb128 | slangasek: thank you! | 21:39 |
| psusi | ok, I am confused as all hell.... make works normally to build/clean/etc this project, but the only thing in the makefile is this: | 21:57 |
| psusi | all check clean distclean install mostlyclean uninstall: @echo "You need to use GNU make (version 3.70 or later)." >&2 | 21:57 |
| NCommander | StevenK, ping | 22:11 |
| NCommander | StevenK, I'm told the linux-lpia-meta upload adding linux-firmware isn't right | 22:11 |
| === robbiew-lunch is now known as robbiew | ||
| slangasek | bryce: did mvo end up talking to you (or anyone) about this scary xorg-server change? | 22:34 |
| TheMuso | cjwatson: disk-detect checks for "No RAID disks" because there may be several disks in a machine that do not have RAID data, and others that do, or thats how I understand it. That was already there when I started doing my dmraid work. | 22:39 |
| NCommander | hey TheMuso | 22:39 |
| TheMuso | Hey NCommander. Seems I got kicked off at some point, even though my net was still active. | 22:40 |
| cjwatson | TheMuso: I'm just in general uncomfortable with human-readable-string checks, and would prefer something based on exit codes (perhaps extending the underlying tools where necessary) | 22:40 |
| NCommander | TheMuso, nice. I successfully have a 2.6.27 linux-ports kernel :-) | 22:40 |
| cjwatson | psusi: check for other makefiles (e.g. GNUmakefile) | 22:40 |
| NCommander | TheMuso, (sorta, there is some sorta makefile bug that prevents it from building the powerpc-smp/powerpc64-smp kernel) | 22:40 |
| TheMuso | cjwatson: dmraid has no exit codes that are of any use. | 22:40 |
| wgrant | TheMuso: Australian Internet being active? Complain to your ISP. | 22:40 |
| cjwatson | TheMuso: hence extending | 22:40 |
| psusi | cjwatson: heh, yea, I found it ;) | 22:40 |
| TheMuso | cjwatson: If you mean extending dmraid, then its impossible to do and make sure its stable for intrepid. | 22:41 |
| cjwatson | TheMuso: sure, I didn't mean for intrepid | 22:41 |
| * TheMuso nods. | 22:41 | |
| TheMuso | I'll look at it for jaunty, if I can get over the crap nature of dmraid as it stands. | 22:41 |
| TheMuso | mathiaz: I'll get to that bug in my bug mail, assuming its filed against one of the installer components of dmraid itself. | 22:42 |
| mathiaz | TheMuso: it's filed agains hw-test and the dmraid package itself. | 22:46 |
| mathiaz | TheMuso: as discussed with cjwatson this is not release critical for intrepid | 22:46 |
| cjwatson | hw-detect. | 22:46 |
| cjwatson | (hwtest is something else) | 22:46 |
| * TheMuso nods. | 22:46 | |
| Keybuk | I so read that as hw-detest | 22:46 |
| Keybuk | which just about sums up my feelings about it | 22:46 |
| cjwatson | now now, it still has some useful functions | 22:47 |
| nxvl | Keybuk: heh | 22:47 |
| * Chipzz pokes TheMuso | 22:47 | |
| Chipzz | TheMuso: I had a problem a while ago with an ubuntu-server install | 22:48 |
| Chipzz | a server with hardware RAID was detected as having software RAID | 22:48 |
| Chipzz | and with hardware RAID I do mean *hardware* RAID ;) | 22:48 |
| Chipzz | not the crappy el-cheapa semi software raid | 22:48 |
| Chipzz | (el-cheapo) | 22:49 |
| cjwatson | Chipzz: that problem is why we now ask a question instead of Just Doing It | 22:49 |
| cjwatson | Chipzz: bug 279288 | 22:49 |
| ubottu | Launchpad bug 279288 in partman-base "User interface exception request: Ask the user if they wish to activate dmraid arrays." [High,Fix released] https://launchpad.net/bugs/279288 | 22:49 |
| Chipzz | cjwatson: ah ok, I was wondering if there was something I could do to help debug why it did that | 22:49 |
| cjwatson | Chipzz: it seems that you had something looking very much like dmraid metadata lying around on your disks, regardless of the current state | 22:50 |
| TheMuso | Chipzz: SOunds like the disks were from a dmraid/Fake RAID array, and they still have the metadata on them. Some BIOSes are very bad in not cleaning up the metadata if the user turns the feature off. | 22:50 |
| Chipzz | TheMuso: no, the RAID is presented as 1 SCSI disk to the OS | 22:51 |
| Chipzz | (mirroring raid) | 22:51 |
| Chipzz | so that would be unlikely, right? | 22:52 |
| TheMuso | Chipzz: thats not what I'm talking about. What I am saying is that the disks still have what looks like dmraid metadata on them, from a previous setup, basically what cjwatson was saying. | 22:52 |
| psusi_ | anyone got any idea why gcc would not complain about multiple definitions of main with -02 but does with -O0? this is fubar... how did this ever compile? | 22:52 |
| TheMuso | Which is why dmraid picked up on them and activated them. | 22:52 |
| Chipzz | TheMuso: which wasn't the case. the previous install was a debian install | 22:52 |
| Keybuk | psusi_: warnings are dependant on optimisation level | 22:52 |
| Chipzz | and some attempts to install ubuntu-server on it I guess | 22:52 |
| TheMuso | Chipzz: Right. | 22:52 |
| Chipzz | well, actually I'm incorrect | 22:52 |
| psusi_ | Keybuk: a vilotion of ODR is not a warning though... it's a link error, hands down | 22:53 |
| Chipzz | the previous install was a VmWare ESX install | 22:53 |
| Chipzz | dunnow if that does anything weird to the disks though | 22:53 |
| Keybuk | psusi_: neither -O0 or -O3 are linker options | 22:53 |
| Keybuk | so I'd guess from your description that you're only talking about warnings at compile stage | 22:53 |
| Keybuk | and simply haven't tried to link yet | 22:53 |
| psusi_ | Keybuk: yea... I know... which is why this is so odd... all I do is change the -O setting in the debian/rules, and it makes it work or not... the makefile is apparently linking several objects into a library, one of which contains a main definition | 22:54 |
| Chipzz | TheMuso: but anyway, I succeeded with installing ubuntu-server on it, but wasn't happy with the settings wrt LVM/encryption I had, so I reinstalled ubuntu-server a second time | 22:54 |
| psusi_ | and then it links this library with another file with its own main to produce a binary | 22:54 |
| Chipzz | by which time the dmraid remnants should have been gone | 22:54 |
| Keybuk | psusi_: one fails, another doesn't? | 22:54 |
| Chipzz | and the 2nd install still wanted to install dmraid | 22:54 |
| psusi_ | with -O2 it actually works, which it shouldn't... when I set -O0 to try and debug something else, it fails to build | 22:54 |
| TheMuso | Chipzz: Well the dmraid metadata is usually always at the end of the disks. | 22:55 |
| Chipzz | TheMuso: any (non-destructive) tests I can run? | 22:55 |
| Keybuk | psusi_: maybe one of the main()s get optimised out at compile-time | 22:55 |
| Keybuk | so the linker only ever sees one? | 22:55 |
| TheMuso | Chipzz: TO be sure you have no metadata lying around, you can run "sudo dmraid -rE" to erase it. | 22:55 |
| psusi_ | hrm.... | 22:55 |
| Chipzz | TheMuso: well the server is installed, so the problem is gone AFA I am concerned, so that won't be necesarry anymore ;) | 22:56 |
| Chipzz | but if it can be of any help to you, I can do some tests if you want to? | 22:56 |
| psusi_ | Keybuk: I can't see how that could happen though, and objdump shows main in both the object and the library yet the linker links them just fine as long as I build with -O2 | 22:57 |
| === dwatson is now known as davewatson | ||
| Keybuk | psusi_: nothing can introduce random appearance and disappearance of a behaviour during debugging quite as effectively as a compiler's attempt at optimisation | 22:57 |
| === psusi_ is now known as psusi | ||
| psusi | Keybuk: so does this look like a bug in gcc to you then? | 22:58 |
| Keybuk | psusi: no, not until you can explain why it behaves that way | 22:58 |
| TheMuso | Chipzz: No I think all is ok at the moment. | 22:58 |
| Keybuk | it doesn't sound like it's producing invalid code, so it's just a curious behaviour that might amuse | 22:59 |
| Chipzz | TheMuso: btw, I have encryption set up on the box | 22:59 |
| Chipzz | TheMuso: maybe that would be the reason for dmraid? | 22:59 |
| Chipzz | or is dmraid not needed for encryption? | 22:59 |
| bryce | slangasek: no not so far | 23:05 |
| slangasek | bryce: huh. well, the upload is in the unapproved queue, could you give a professional opinion on whether I should accept it? :) | 23:05 |
| bryce | ok, how do I view the unapproved queue? | 23:06 |
| slangasek | bryce: bug #278112, if you don't have the bug number | 23:06 |
| psusi | Keybuk: is there any time gcc is supposed to accept a library and an object as inputs to link when both contain definitions of main? I wouldn't think so, but man I'm not sure which end is up now | 23:06 |
| ubottu | Launchpad bug 278112 in xorg-server "Screensaver doesn't start" [Medium,In progress] https://launchpad.net/bugs/278112 | 23:06 |
| bryce | thanks | 23:06 |
| slangasek | probably easier to review the debdiff he posted there | 23:06 |
| superm1 | slangasek, do you want me to post a debdiff for splitting that fglrx package up somewhere to review how I did it, or just upload it and you'll take a look then? | 23:07 |
| slangasek | superm1: upload please | 23:07 |
| superm1 | slangasek, okay | 23:07 |
| slangasek | uploads to the unapproved queue give me an implicit debdiff :) | 23:07 |
| Keybuk | psusi: you'd have to prove that was what it was doing | 23:08 |
| cjwatson | bryce: queue should be accessible from https://launchpad.net/ubuntu/intrepid/+queue | 23:08 |
| Keybuk | I'd be more inclined to believe that something else was happening | 23:09 |
| psusi | Keybuk: objdump foo.a -t | grep main and objudump bar.o -t | grep main show they each have a main, which they should seeing as how there is one in bar.c and one in a source file that is compiled and linked into foo.a | 23:09 |
| Keybuk | does objdump work on a .a file? :p | 23:09 |
| slangasek | no | 23:09 |
| psusi | umm.... yea? | 23:10 |
| slangasek | oh, objdump -t does, yes | 23:10 |
| bryce | cjwatson: aha | 23:10 |
| Keybuk | does it? | 23:10 |
| psusi | yet somehow these two files are linked to produce a working binary.... but only if I leave -O at 2 in the rules | 23:10 |
| Keybuk | psusi: assumingly it discards one of them | 23:11 |
| slangasek | yes, gcc is good at throwing stuff out of .a files that it doesn't need | 23:11 |
| bryce | slangasek: ok the patch looks alright to me, although I'm curious if there are implications you're concerned about? | 23:11 |
| psusi | Keybuk: yea... but it shouldn't... and why does it only do it with -O2? | 23:11 |
| Keybuk | psusi: why shouldn't it? | 23:11 |
| slangasek | bryce: I'm always concerned about the implications of patching the core X server :) | 23:11 |
| Keybuk | as slangasek says, gcc has a long and honourable history of ignoring bits of .a files | 23:11 |
| psusi | Keybuk: because it violates the One Definition Rule | 23:11 |
| Keybuk | what One Definition Rule? | 23:12 |
| Keybuk | we're talking about gcc not g++, no? | 23:12 |
| psusi | THE ODR that is part of C and C++ ;) | 23:12 |
| Keybuk | there is no ODR in C | 23:12 |
| psusi | ?! | 23:13 |
| slangasek | C is odrless | 23:14 |
| Keybuk | and deadly | 23:14 |
| psusi | no way | 23:14 |
| Keybuk | way | 23:14 |
| psusi | the linker always complains if you try defining two symbols with the same name | 23:14 |
| psusi | it has to; it has no way of knowing which one you want | 23:15 |
| Keybuk | it's hard for you to justify such a statement when talking about an issue where the linker isn't complaining ;) | 23:15 |
| psusi | well, then why does it complain with -O0 ;) | 23:15 |
| Keybuk | because with optimisation enabled, gcc discards various bits of .a files first | 23:15 |
| Keybuk | including, assumedly, your object file with main() in it | 23:15 |
| Keybuk | so by the time it comes to link, it only has the one from the object file | 23:16 |
| RicardoPerez | Hi! Can anybody test if left-arrow key goes slower than right-arrow key when you previously do: xset r rate 10 50 | 23:16 |
| RicardoPerez | Thanks in advance | 23:16 |
| psusi | why would it disgard the main in the library when optimizing though? | 23:16 |
| slangasek | bryce: so should I go ahead and let this xorg-server change in? | 23:17 |
| psusi | it's referenced.... so it shouldn't discard it | 23:17 |
| slangasek | no, "main" is referenced | 23:17 |
| slangasek | and it already has one of those, so it can toss out the other one | 23:17 |
| psusi | how is that not a mal formed program in C? | 23:17 |
| slangasek | why are we even having this discussion? Why have you not simply fixed your code to not put functions named "main" in a static lib? | 23:17 |
| Keybuk | why should it be malformed? | 23:18 |
| psusi | because I'm not sure how this crazy makefile is working | 23:18 |
| psusi | Keybuk: ODR ;) | 23:18 |
| Keybuk | that's C++ | 23:18 |
| psusi | I could have sworn that came from C | 23:18 |
| Keybuk | nope | 23:18 |
| psusi | and it's absolutely insane not to have it | 23:18 |
| Keybuk | C doesn't have rules | 23:18 |
| slangasek | haha | 23:19 |
| Keybuk | C has gaping chasms the standard refers to as "undefined" | 23:19 |
| Keybuk | or their other favourite cop-out | 23:19 |
| Keybuk | "implementation defined" | 23:19 |
| Keybuk | I'm not entirely sure that the C standard even talks about linking | 23:21 |
| slangasek | I'm not aware that it does | 23:22 |
| cjwatson | it talks about *linkage*, which is related but not the same thing | 23:22 |
| cjwatson | actually, it does talk about linking a bit | 23:23 |
| cjwatson | e.g. 5.1.1.1 "Translation units may be separately translated and then linked to produce an executable program" | 23:23 |
| cjwatson | elsewhere it says that if an identifier has both internal and external linkage then the result is undefined | 23:24 |
| Keybuk | yeah, was just reading 5.1 | 23:24 |
| bryce | slangasek: yes I think it should be fine | 23:24 |
| cjwatson | many things are erroneous C (in the sense that they are not defined) but compilers/linkers are not required to produce diagnostics for them | 23:24 |
| slangasek | bryce: accepting, thanks | 23:24 |
| bryce | slangasek: no red flags are jumping out; not likely to cause crashes or serious regressions, just a 2-line change, etc. | 23:25 |
| slangasek | bryce: so you don't think it's going to cause horrible memory leaks by returning early? :) | 23:25 |
| superm1 | bryce, has the fix to xorg-server regarding nv that you posted been tested/decided upon yet? | 23:25 |
| Keybuk | cjwatson: 6.9.5 maybe? | 23:25 |
| TheMuso | cjwatson: thaanks for the patch to dmraid, I just need someone to test the patched version with virtio block devices. mathiaz How do you set up a vm with virtio block devices, so I can test this? | 23:26 |
| Keybuk | that's about the closest I can see | 23:26 |
| Keybuk | but amusingly, by its very working, appears to exclude main() :p | 23:26 |
| cjwatson | Keybuk: you have a different version of the standard than I do; my 6.9 ("External definitions") only goes up to .2 ("External object definitions") | 23:29 |
| mathiaz | TheMuso: are you using libvirtd or kvm from the command line directly? | 23:29 |
| cjwatson | I should get an updated version at some point | 23:29 |
| Keybuk | cjwatson: I have BS ISO/IEC 9899:1999 (C99 inc TG1) | 23:29 |
| Keybuk | http://www.amazon.co.uk/C-Standard-British-Standards-Institute/dp/0470845732/ | 23:30 |
| slangasek | superm1: better than a -XlibAMD would be using the debian/shlibs.local that I suggested in the bug report | 23:33 |
| TheMuso | mathiaz: I usually use libvirt. | 23:34 |
| slangasek | superm1: this lets you statically declare that libstdc++.so.5 is contained in the package libstdc++5 without build-depending on it, which is a pretty safe thing to assume, and safer than assuming that the lib dependencies of libMDXvBA.so will remain constant | 23:34 |
| mathiaz | TheMuso: ok - so I'd suggest that you dumpxml the configuration of the host and modify the section about drive definition | 23:34 |
| slangasek | superm1: also, if you're calling dh_shlibdeps -XlibAMD, then ${shlibs:Depends} will be /completely/ empty for this package, so no lib deps other than libstdc++5 will be picked up either | 23:34 |
| superm1 | slangasek, ah yeah, that's a valid repercussion | 23:35 |
| TheMuso | mathiaz: Right, what do I change? | 23:35 |
| slangasek | superm1: have I explained adequately for you to reupload with that change? if so, I'll reject this package back out of the queue | 23:35 |
| superm1 | slangasek, yeah. let me make it and verify that it still handles correctly locally and i'll reupload | 23:36 |
| slangasek | ok, thanks | 23:36 |
| mathiaz | TheMuso: in the disk definition, change the target element to : <target dev='vda' bus='virtio' /> | 23:36 |
| TheMuso | mathiaz: Right thanks. | 23:36 |
| mathiaz | TheMuso: the important part is that the dev attribute starts with v | 23:36 |
| mathiaz | TheMuso: and the bus is virtio | 23:36 |
| TheMuso | mathiaz: Right. | 23:36 |
| mathiaz | TheMuso: then reload the configuration of the machine with the define command from virsh | 23:37 |
| TheMuso | mathiaz: Ok thanks will get that tested. | 23:37 |
| ArneGoetje | slangasek: those language codes don't have locale data available, that's why there is no language-pack-base package and the language is unusable. To fix this we need locale data for those languages. | 23:38 |
| slangasek | ArneGoetje: ok, where do we get such locale data? :) | 23:39 |
| slangasek | seeing that these packages will block DVD builds until they're either fixed, or removed from main | 23:39 |
| cjwatson | let's just remove those packages? | 23:40 |
| ArneGoetje | slangasek: then remove them for now. We can't support them anyways. | 23:40 |
| cjwatson | I don't see a good reason to keep them | 23:40 |
| slangasek | fine with me, yes | 23:40 |
| cjwatson | ArneGoetje: can you fix langpack-o-matic not to generate them again | 23:40 |
| cjwatson | ? | 23:40 |
| cjwatson | until locale data exists | 23:40 |
| ArneGoetje | slangasek: actually, langpack-o-matic should have just skipped them if there is no locale data available... I will take a look at it. | 23:40 |
| slangasek | ok; nuking the packages, in the meantime | 23:41 |
| ArneGoetje | cjwatson: will do | 23:41 |
| slangasek | ArneGoetje: also, language-support-extra-de is uninstallable; I'm thinking you don't want me to nuke that one | 23:41 |
| cjwatson | it's also not seeded ... | 23:41 |
| cjwatson | all the other language-support-extra-* are in universe | 23:42 |
| slangasek | oh, perhaps that's why it's uninstallable | 23:42 |
| ArneGoetje | slangasek: the translation teams for those languages would need to generate locale data and submit them to upstream glibc | 23:42 |
| cjwatson | yeah | 23:42 |
| slangasek | right, I'll demote that shortly then | 23:42 |
| cjwatson | I've demoted it | 23:42 |
| slangasek | ok | 23:42 |
| ArneGoetje | cjwatson: yes, the l-s-extra packages belong to universe. | 23:43 |
| * lamont wonders if there's a good writeup somewhere on using a bluetooth headset on hardy | 23:55 | |
| lamont | or intrepid, for that matter | 23:55 |
| ScottK | lamont: If you're on KDE it'd really simple since it's currently broken. | 23:56 |
| StevenK | NCommander: Yeah, I've been thinking about it, and lpia-lrm should Depend on it | 23:56 |
| lamont | ScottK: lol | 23:56 |
| superm1 | lamont, sco or a2dp? | 23:57 |
| superm1 | lamont, if a2dp, just pair with it, and drop this http://paste.ubuntu.com/60294/ in ~ and go. | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
