| asac | slangasek: not much of a problem in the patch itself ... more about the fact that we try to keep firefox-3.1 branch more or less in sync with our firefox-3.0 branch | 00:00 |
|---|---|---|
| slangasek | asac: ok, just checking :) | 00:01 |
| asac | slangasek: well. one maybe issue is that its a bashism isnt it? | 00:01 |
| slangasek | bryce: mumble, why did xscreensaver 5.07-0ubuntu1 just now appear in the archive with a changelog dated from 28Aug? | 00:01 |
| asac | i think its ok to use bash in general, but we tried to prevent that in the past | 00:01 |
| slangasek | asac: %% and ## are not bashisms, if that's what you mean | 00:01 |
| slangasek | those are posix; the bashism is // | 00:02 |
| asac | slangasek: ok. then all fine | 00:02 |
| bryce | slangasek: probably because it had been sitting in the sponsor queue for a long long time | 00:02 |
| asac | its just that we also have to look what we can do better in the future. all this is a bit hairy. especially considering that we still have patches that hard code what gets written into gconf for the www-browser user preference :) | 00:02 |
| slangasek | bryce: :/ | 00:03 |
| asac | and we would like to have a better $0 ... if possible ;) | 00:03 |
| slangasek | and the changelog lacks any mention of the changed Recommends:, sigh | 00:03 |
| slangasek | bryce: in fact, this upload clobbered the changes from 5.05-1ubuntu2... checking to see if any other fixes went missing... | 00:05 |
| slangasek | nope, just that one | 00:06 |
| bryce | slangasek: need me to do anything? | 00:10 |
| slangasek | bryce: I've got it, thanks... I'm just my usual grumbly self about regressions introduced in non-obvious ways :) | 00:11 |
| bryce | slangasek: ok cool, sorry about not catching that. | 00:11 |
| === cr3_ is now known as cr3 | ||
| ion_ | Heh, the acpi package still uses old-style changelog entries. | 01:53 |
| bryce | is there an easy way to check what versions of a package were included in a given alpha release? | 02:27 |
| StevenK | bryce: The .manifest | 02:28 |
| bryce | ah thanks | 02:28 |
| bryce | hmm, where can I find .manifest's for alpha3 and alpha4? not spotting them immediately on cdimage.ubuntu.com | 02:29 |
| cjwatson | or .list if you're looking at alternate/server installs | 02:29 |
| cjwatson | they aren't published anywhere unfortunately | 02:29 |
| bryce | hrm | 02:30 |
| bryce | I've got a reporter who says an issue did not exist in alpha 3, and started appearing with alpha 4, so to upstream the bug I'd like to translate that into the appropriate package version numbers | 02:31 |
| cjwatson | what package do you care about? | 02:31 |
| bryce | xserver-xorg-video-ati (and xorg-xserver) | 02:31 |
| cjwatson | we have an archive of alpha-4 (but for some reason not alpha-3) on antimony | 02:32 |
| bryce | (hmm, maybe I should start snapshotting version numbers of X packages) | 02:32 |
| cjwatson | xorg-xserver> YM xserver-xorg? or xserver-xorg-core? | 02:32 |
| bryce | xserver-xorg-core | 02:32 |
| cjwatson | alpha-4 had xserver-xorg-video-ati 1:6.9.0+git20080802.1f3eee36-1ubuntu1, xserver-xorg-core 2:1.4.99.906-1ubuntu3 | 02:33 |
| Hobbsee | bryce: you can check dates of uploads corresponding to the release schedule too, if you wanted to. | 02:33 |
| cjwatson | yeah, that's probably the easiest approach | 02:34 |
| Hobbsee | (assumign it didn't get updated terribly often) | 02:34 |
| bryce | excellent thanks. Yeah from the changelog it looks like we had perhaps 6.9.0-1 in alpha3 | 02:34 |
| bryce | Hobbsee: yeah that's what I've usually done, but it's a touch ambiguous in this case | 02:34 |
| Hobbsee | bryce: darn :( | 02:35 |
| bryce | -ati was updated pretty frequently both by us and debian, and we sync'd from them for much of this cycle so the changelog dates don't necessarily indicate when the package was present in our archives | 02:35 |
| bryce | but I think this info is sufficient, thanks | 02:36 |
| cjwatson | look at the publication dates in LP | 02:36 |
| bryce | (this is for bug #264462 btw) | 02:36 |
| ubottu | Launchpad bug 264462 in xserver-xorg-video-ati "Radeon Driver fails to load on 2 Sep daily [ATI HD3870]" [High,Triaged] https://launchpad.net/bugs/264462 | 02:36 |
| cjwatson | https://launchpad.net/ubuntu/+source/xserver-xorg-video-ati | 02:36 |
| bryce | ah good point | 02:36 |
| cjwatson | you can hover over the date to get an exact date and time | 02:37 |
| cjwatson | confusingly when it says "superseded" that gives you the upload time of the *next* package in chronological order in that series | 02:38 |
| cjwatson | i.e. it gives you current publication state plus the time when it changed to that state | 02:38 |
| bryce | hum, interesting | 02:41 |
| ScottK | NCommander: Sure thing. | 03:05 |
| ScottK | NCommander: Which? | 03:05 |
| NCommander | ScottK, we decided not to fix in intrepid (which I don't get but yeah ...) | 03:07 |
| ScottK | NCommander: OK. Wanna update amule? | 03:07 |
| NCommander | New upstream? | 03:09 |
| ScottK | NCommander: Yeah. | 03:09 |
| NCommander | You writing the FFe? | 03:09 |
| ScottK | No, you are. | 03:09 |
| NCommander | I am? | 03:09 |
| ScottK | I'll give it a first ack though. See Bug 260471 | 03:09 |
| ubottu | Launchpad bug 260471 in amule "[intrepid] update aMule to version 2.2.2" [Medium,In progress] https://launchpad.net/bugs/260471 | 03:10 |
| ScottK | Part of what 'update' entails. I just don't have the time. | 03:10 |
| NCommander | Does Launchpad accept .bz2 original tarballs yet? | 03:11 |
| NCommander | ScottK, I think we can simply sync from experimental | 03:13 |
| ScottK | NCommander: I'm fine with whatever works. | 03:13 |
| Hobbsee | defien 'works' here? :P | 03:13 |
| ScottK | Please steal it from me. | 03:13 |
| NCommander | ScottK, can we straight sync from Debian? | 03:14 |
| ScottK | Meaning people don't wine a motu-release about amule being old again. | 03:14 |
| ScottK | NCommander: Dunno. You tell me. | 03:14 |
| NCommander | from experimental? | 03:14 |
| NCommander | I know we can from sid | 03:14 |
| Hobbsee | yes, you can. | 03:14 |
| ScottK | It's technically possible. | 03:14 |
| NCommander | But I never requested from experimental | 03:14 |
| Hobbsee | of course, you can sync it yourself, too. | 03:14 |
| * NCommander is seeing if the Ubuntu diverance is still needed | 03:14 | |
| NCommander | Hobbsee, some of us aren't MOTU | 03:14 |
| Hobbsee | NCommander: bribes accepted. | 03:14 |
| * ScottK kicks NCommander in the appropriate place to get his application in. | 03:14 | |
| NCommander | ScottK, I was told I won't pass the vote until I've been in a full cycle | 03:15 |
| NCommander | (two 0s, and a -1 are likely) | 03:15 |
| NCommander | That's DIF jaunty | 03:15 |
| ScottK | NCommander: Is you have enough sponsors speaking for you, my predication is it won't matter. | 03:15 |
| Hobbsee | NCommander: if you're unlucky, someone (*glares at Mithrandir) will put you forward anyway. | 03:16 |
| NCommander | Hobbsee, I can be sponsored for MOTUship without doing anything? | 03:16 |
| * NCommander got UDS sponsorship that way | 03:16 | |
| TheMuso | NCommander: If your work and your demonstrated abilities are exceptional. | 03:16 |
| Hobbsee | NCommander: sure. I mean, you have to talk about it afterwards, but you don't have to be teh first one to send mail applying for it. | 03:16 |
| Hobbsee | NCommander: oh, you're coming? excellent. | 03:17 |
| Hobbsee | NCommander: how normal that is, i'm not sure. | 03:18 |
| Hobbsee | NCommander: oh, and people might just stop sponsoring your stuff, and tell you to apply instead :P | 03:18 |
| NCommander | Hobbsee, then they are only shooting themselves in the foot :-) | 03:24 |
| * NCommander is coding in x86 ASM | 03:25 | |
| NCommander | Hobbsee, I'm writing my application :-) | 03:25 |
| emet | NCommander, AT&T or Intel syntax? | 03:26 |
| NCommander | AT&T | 03:27 |
| NCommander | :-) | 03:27 |
| RAOF | NCommander: I hope that's real mode ASM. None of this flat-memory-model laziness! | 03:27 |
| NCommander | I need it to compile in GAS | 03:27 |
| NCommander | RAOF, thats my core dev application | 03:27 |
| NCommander | This one will simply be an ELF application | 03:27 |
| NCommander | Hrm | 03:27 |
| NCommander | Or | 03:27 |
| NCommander | I could write a amd64 ASM app | 03:27 |
| emet | gas can compile Intel syntax too | 03:27 |
| NCommander | Oooh | 03:27 |
| NCommander | That must be a relatively new feature | 03:28 |
| RAOF | You know what you really want to do? Raw CIL! | 03:28 |
| NCommander | Ew | 03:28 |
| emet | NCommander, what are you doing in assembly may I ask? I'm learning x86 assembly right now, so maybe can share code or something | 03:30 |
| NCommander | emet, I'm writing my MOTU application | 03:30 |
| NCommander | :-) | 03:30 |
| emet | in assembly? O_o | 03:31 |
| TheMuso | heh | 03:31 |
| NCommander | Yes | 03:31 |
| NCommander | In assembly | 03:31 |
| * Hobbsee wonders if MOTU applications are automatically rejected if they are written in brainfuck. | 03:31 | |
| NCommander | Actually | 03:31 |
| NCommander | That idea did cross my path | 03:31 |
| NCommander | But x86 is more like 32-bit brainfuck | 03:32 |
| emet | no if you do anything useful in brainfuck that deserves a medal | 03:32 |
| NCommander | mcasadevall@blacksteel:~/motu-application$ gcc test.s -m32 | 03:32 |
| NCommander | /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.2/libgcc.a when searching for -lgcc | 03:32 |
| NCommander | Yah know | 03:32 |
| NCommander | Screw it | 03:32 |
| NCommander | brainfuck it is | 03:32 |
| * NCommander writes an application to change ASCII strings to brainfuck | 03:32 | |
| emet | as -o test test.s | 03:32 |
| NCommander | emet, no, I'm on x86_64 | 03:32 |
| emet | oh okay | 03:32 |
| NCommander | I mean | 03:32 |
| NCommander | I could write it in x86_asm | 03:33 |
| NCommander | er | 03:33 |
| RAOF | NCommander: Got gcc-multilib installed? | 03:33 |
| NCommander | x86_64 | 03:33 |
| Hobbsee | emet: i recently saw an application that wrote out the beer song. | 03:33 |
| Hobbsee | and a few other interesting ones. | 03:33 |
| emet | that's cool | 03:33 |
| NCommander | Is there a brainfuck compiler in Ubuntu? | 03:33 |
| * NCommander notes that would be a preq | 03:33 | |
| emet | yes | 03:33 |
| NCommander | Hrm | 03:33 |
| NCommander | x86 asm or brainfuck | 03:33 |
| NCommander | hrm ... | 03:33 |
| emet | beef | 03:33 |
| emet | !info beef | 03:34 |
| emet | :o | 03:34 |
| ubottu | beef (source: beef): flexible Brainfuck interpreter. In component universe, is extra. Version 0.0.6-1 (hardy), package size 7 kB, installed size 60 kB | 03:34 |
| Hobbsee | NCommander: or both :P | 03:34 |
| Hobbsee | NCommander: half in one, half in teh other? | 03:34 |
| NCommander | We really have a package with fuck in its description in Ubuntu? | 03:35 |
| emet | !info bitchx | 03:36 |
| ubottu | Package bitchx does not exist in hardy | 03:36 |
| emet | :o | 03:36 |
| ScottK | That one was removed due to it's consistent security history, IIRC | 03:36 |
| stdin | NCommander: it's a language | 03:36 |
| stdin | well, kinda | 03:36 |
| emet | notice the size too | 03:37 |
| emgent | http://www.reghardware.co.uk/2008/10/08/asus_eee_box_virus/ | 03:44 |
| emgent | nice. | 03:44 |
| NCommander | Ok, I do remember x86 ASM | 03:44 |
| * NCommander just managed to write hello world | 03:45 | |
| ion_ | emgent: Heh | 03:46 |
| jturek | hey guys anybody get "wireless event too big" messages in their virtual console running intrepid? | 04:01 |
| jturek | bug 267063 was filed about it, and i put in my dmesg output in that bug as well | 04:02 |
| ubottu | Launchpad bug 267063 in linux "iwl4965 - wireless event too big (366) and 2.6.27-2 regression" [Medium,Triaged] https://launchpad.net/bugs/267063 | 04:02 |
| jturek | it still exists in 2.6.27-6 | 04:03 |
| jturek | is there a console based program to view and edit bugs? or is it best to use Lynx/Links | 04:06 |
| ScottK | Not for Ubuntu. | 04:06 |
| ScottK | Launchpad works pretty well with no css in text based browsers, however. | 04:07 |
| jturek | ScottK - Thanks | 04:07 |
| jturek | Scott what text browser is maintained and renders sites the best? Links/Lynx/Elinks | 04:08 |
| jturek | ? | 04:08 |
| === jamesh_ is now known as jamesh | ||
| TheMuso | jturek: IMO elinks is the best. | 04:13 |
| lukehasnoname | cjwatson: Bug #96435 , I added a comment for you to look at, as maintainer of the bug. I don't know if you get emails at every post. | 04:16 |
| ubottu | Launchpad bug 96435 in oem-config "[apport] oem-config-dm crashed with XStartupError in run()" [Medium,Confirmed] https://launchpad.net/bugs/96435 | 04:16 |
| pitti | Good morning | 06:45 |
| StevenK | Morning pitti | 06:46 |
| pitti | ScottK: private bug dups>neither really; I still think we shouldn't make crash bugs public by default | 06:46 |
| === tkamppeter_ is now known as tkamppeter | ||
| yao_ziyuan | i wonder, | 07:36 |
| yao_ziyuan | when setting up flashplugin-nonfree, | 07:36 |
| yao_ziyuan | it downloads http://download.macromedia.com/pub/labs/flashplayer10/flashplayer10_install_linux_091508.tar.gz | 07:36 |
| yao_ziyuan | does it then check some fingerprint? | 07:36 |
| yao_ziyuan | because i'm in china, | 07:36 |
| yao_ziyuan | and i'm concerned if this download can be altered in the middle by the government | 07:37 |
| Treenaks | it checks the md5sum | 07:37 |
| yao_ziyuan | Treenaks: what is the source of the md5sum? | 07:37 |
| Treenaks | yao_ziyuan: the package | 07:37 |
| Treenaks | yao_ziyuan: it checks the md5sum of the .tar.gz first, then of the libflashplayer.so (plugin) file | 07:38 |
| Treenaks | and there are 2 md5sums in the postinst in the package | 07:38 |
| yao_ziyuan | but does it check the package's fingerprint before checking the .tar.gz? | 07:39 |
| yao_ziyuan | the package itself's md5sum | 07:39 |
| yao_ziyuan | i think so. | 07:39 |
| TheMuso | yao_ziyuan: apt/dpkg checks the md5sum before unpacking the package. | 07:39 |
| Treenaks | yao_ziyuan: yes, apt will warn you if the package's GPG signature doesn't match (and won't install the package) | 07:39 |
| yao_ziyuan | good | 07:40 |
| yao_ziyuan | i just ctrl+break and used sudo torify apt-get install -f to make sure | 07:40 |
| Treenaks | yao_ziyuan: it's very hard to get apt to install packages that don't match the md5sum/sha1sum from the (gpg-signed) packages file | 07:41 |
| wgrant | TheMuso: dpkg won't check a sig. | 07:41 |
| wgrant | apt will. | 07:41 |
| TheMuso | wgrant: Right, wasn't quite sure where in the stack it is checked, but that makes sense. | 07:41 |
| wgrant | Unless you say yes to the 'COULD NOT BE AUTHENTICATED' warning. | 07:41 |
| wgrant | In which case you are strange. | 07:41 |
| Treenaks | wgrant: selectively paranoid :) | 07:41 |
| yao_ziyuan | i think displaying a line "md5sum of flashplayer....tar.gz verified" can calm users like me | 07:41 |
| wgrant | TheMuso: dpkg does check the md5sums, but the md5sums in the .deb aren't signed. | 07:41 |
| TheMuso | wgrant: yeah true. | 07:42 |
| Treenaks | wgrant: but if the hash of a .deb doesn't match the hash in the Packages file, apt will complain even harder than 'could not be authenticated', and just refuse to install | 07:42 |
| Treenaks | afaik | 07:42 |
| wgrant | Treenaks: Oh, true. | 07:42 |
| wgrant | Treenaks: It'll give "Hash sum mismatch" | 07:42 |
| wgrant | Or something similar. | 07:42 |
| wgrant | But one can easily enough fake unsigned Packages files. | 07:42 |
| Treenaks | just deny access to the signature file | 07:43 |
| Treenaks | I think? | 07:43 |
| wgrant | Treenaks: Quite possibly. | 07:43 |
| yao_ziyuan | i pay close attention to apps who download executables from their own websites | 07:44 |
| yao_ziyuan | like sun java's autoupdate, firefox's check for browser update | 07:44 |
| wgrant | Those apps should generally be shot unless they're apt. | 07:44 |
| yao_ziyuan | adobe reader's auto update | 07:44 |
| Treenaks | yao_ziyuan: Ubuntu's firefox doesn't do that check, I think | 07:45 |
| yao_ziyuan | i know | 07:45 |
| wgrant | Treenaks: It does for extensions. | 07:45 |
| yao_ziyuan | extensions are https | 07:45 |
| yao_ziyuan | if an extension doesn't use a https update link, firefox will disable updating it | 07:45 |
| wgrant | Ah, good. | 07:47 |
| Treenaks | yao_ziyuan: Debian/Ubuntu people tend to be very paranoid about downloaded software as well | 07:47 |
| StevenK | pitti: I get a timeout error trying to give back linux-restricted-modules-lpia, can you wave buildd.py at it? | 07:57 |
| pitti | StevenK: done, but it's in depwait; nothing to kick here | 08:05 |
| StevenK | pitti: Yeah, it did itself, thanks. | 08:05 |
| NCommander | Hey StevenK | 08:23 |
| seb128 | pitti: hey | 08:49 |
| pitti | bonjour seb128 | 08:51 |
| seb128 | pitti: the retracer is chocking on bug #279171 | 08:51 |
| ubottu | Bug 279171 on http://launchpad.net/bugs/279171 is private | 08:51 |
| seb128 | pitti: rather the duplicate checking doesn't like it, can't download because needs > 1 value to unpack error | 08:53 |
| seb128 | pitti: is that a known bug? | 08:55 |
| pitti | seb128: ah, it's because the original reporter changed the description to have stuff below the apport report, fixing | 08:58 |
| seb128 | pitti: thanks! | 08:58 |
| pitti | seb128: description updated, should work now | 08:59 |
| seb128 | pitti: "Report is a duplicate of #277616 (fixed in version 0.5~beta1-0ubuntu3)" | 09:01 |
| seb128 | pitti: danke schön | 09:01 |
| seb128 | siretart: hey, do you tag bugs for retracing sometime? | 09:04 |
| seb128 | siretart: the retracers are just set up for hardy and intrepid, so no need to tag crash sent before that, launchpad doesn't show who tagged bugs but I came accross an old bug you triaged recently why was tagged for retracing so in case you added the tag | 09:05 |
| persia | seb128, Is that a disk space issue, or just convenience? I'd think ideally the retracers would cover all supported releases + the development release. | 09:10 |
| seb128 | persia: the retracer are lot of maintainance work, and eat some gigabytes of ram and load the porter box a lot already | 09:11 |
| seb128 | persia: I'm limited to the intrepid instance and stopping those every now and then to run the hardy ones | 09:11 |
| seb128 | because hardy and intrepid on i386 and amd64 makes the box explode under the load | 09:12 |
| siretart | seb128: oh, I see | 09:12 |
| siretart | seb128: what shall I do with failed retraces then? | 09:12 |
| seb128 | it's not worth the trouble to try to set retracers for older version right now seeing how many bugs we can on before hardy versions | 09:12 |
| persia | seb128, Completely understood. Thanks for the explanation. | 09:13 |
| seb128 | siretart: clean those manually | 09:13 |
| seb128 | I'm wondering what to do after intrepid though | 09:13 |
| seb128 | we will need to keep hardy, intrepid retracers | 09:13 |
| persia | And jaunty. Could more hardware be requested? | 09:15 |
| seb128 | siretart: I usually ask if the bug still happens on the current version and to attach an updated stacktrace or use apport to send a new report if that's the case | 09:15 |
| seb128 | persia: right and jaunty, I was listing the non current versions to have retraced | 09:16 |
| seb128 | persia: not sure if hardware is the reply there, ideally those should be moved to a non porter box and we reworked and optimized | 09:16 |
| seb128 | persia: we are spending way too much time to fix upgrade issues, fighting python-launchpad-bugs which make those crash, etc, it would be nice to have something better | 09:17 |
| seb128 | but that would require somebody have some free cycles to spend on those | 09:18 |
| seb128 | cycles not in sense of ubuntu cycles, just some days should be enough ;-) | 09:18 |
| persia | How do the retracers work? Is there source people can fiddle with? | 09:19 |
| pitti | persia: we are also limited by the availability of dbgsym packages | 09:19 |
| persia | pitti, That's an ongoing bug. Haven't we generated -dbgsym for most packages yet? | 09:19 |
| pitti | persia: we did, but we still don't have them for e. g. gutsy | 09:20 |
| siretart | seb128: with 'cleaning' you mean 'removing the core dump, unmark the bug as private and ask submitter for a manual retrace', right? | 09:20 |
| persia | pitti, Sure. I'm more thinking about the future than the past. | 09:20 |
| seb128 | siretart: right | 09:20 |
| seb128 | siretart: <seb128> siretart: I usually ask if the bug still happens on the current version and to attach an updated stacktrace or use apport to send a new report if that's the case | 09:20 |
| siretart | seb128: okay. I've already done so for some bugs in the past. will keep that up for future ones. thanks for notifying me | 09:21 |
| seb128 | siretart: you're welcome ;-) | 09:21 |
| === glatzor_ is now known as glatzor | ||
| === seb128_ is now known as seb128 | ||
| frafu | Hello seb128. Today, the update of ubuntu intrepid shipped a new version of gdm. Could you please tell me whether there was a with the patch supplied in bug#264834, or was there any other problem? | 10:21 |
| seb128 | frafu: hi, looking | 10:23 |
| seb128 | bug #264834 | 10:23 |
| ubottu | Launchpad bug 264834 in gdm "RFE: Add gesture to start onboard and mousetweaks at login (patch supplied)" [Undecided,New] https://launchpad.net/bugs/264834 | 10:23 |
| seb128 | frafu: oh, there is just too many bugs open to keep track of everything, the sponsor team should be subscribed if there is something to sponsor | 10:24 |
| frafu | ok; I was not aware of it; I just subscribed ubuntu-main-sponsors to it. Correct? | 10:28 |
| seb128 | frafu: right | 10:29 |
| frafu | thanks | 10:30 |
| seb128 | you're welcome | 10:31 |
| seb128 | the patch will likely be uploaded today | 10:31 |
| frafu | good news | 10:31 |
| === asac_ is now known as asac | ||
| === thegodfather is now known as fabbione | ||
| asac | Riddell: could you look if there are more changes for knetworkmanager? there appears to be still a bunch of complains in 259278 | 11:11 |
| asac | Riddell: also ... have you tried the kde 4 nm? i think wstephenson said to me that he properly migrated the dbus api to the latest there | 11:11 |
| asac | while hschaa only updated a few things he thought were necessary to get the minimum features working again | 11:11 |
| Riddell | there's no new changes in knetworkmanager | 11:13 |
| Riddell | kde 4 nm is still at a very early stage | 11:13 |
| asac | ok | 11:23 |
| asac | Riddell: is knetworkmanager used at all in kubuntu by default? reason is that i hear quite small amount of noise because of all these knetworkmanager issues | 11:24 |
| asac | could also be that most works now and that the noise left is because they have other issues (and just happen to use knetworkmanager) | 11:25 |
| mdz | does anyone happen to know how the LCD backlight brightness can be adjusted from userspace on Lenovo thinkpads? | 11:26 |
| mdz | I'm trying to work out what's causing bug 280646 | 11:27 |
| ubottu | Launchpad bug 280646 in linux "ACPI brightness events no longer work on ThinkPad T61" [Undecided,New] https://launchpad.net/bugs/280646 | 11:27 |
| * Hobbsee presumes the answer is not function+up? | 11:27 | |
| Hobbsee | or the applet? | 11:27 |
| mdz | Hobbsee: the bug is that the hotkeys aren't working, so I'm looking for how it's supposed to work behind the scenes | 11:27 |
| Riddell | asac: yes it's the default, it works for me, what's the noise? | 11:27 |
| mdz | e.g. what command can I run to manually set the brightness | 11:27 |
| Hobbsee | mdz: ahh. No idea, then :) | 11:28 |
| mdz | my research so far seems to indicate that it isn't handled in hardware on this model, and something in userspace needs to handle the ACPI event and tell it what to do | 11:28 |
| mdz | the applet doesn't work either, I guess I can check what that's trying to do | 11:29 |
| TheMuso | mdz: Is there anything in sysfs that allows you to tweak it by echoing values to something? | 11:29 |
| Hobbsee | mdz: no idea on whether it'll work on that particular machine, but editing /proc/acpi/video/VGA/LCD/brightness is supposed to do it. | 11:29 |
| Hobbsee | ie, sudo echo –n 100 > /proc/acpi/video/VGA/LCD/brightness for full brightness. | 11:30 |
| TheMuso | Hobbsee: I thought all that stuff was in sysfs now. | 11:30 |
| mdz | hobbsee: was just looking at that, will try | 11:30 |
| Hobbsee | TheMuso: may well be. *shrug*. I already said above i had no idea, so now i'm back to guess work :) | 11:30 |
| mdz | hobbsee: yep, that works | 11:30 |
| asac | Riddell: mostly people claiming that it doesnt work in the bug i posted | 11:30 |
| Hobbsee | mdz: \o/ | 11:30 |
| mdz | hobbsee: so the next question becomes, what maze of scripts is supposed to twiddle that value and where is it going wrong? | 11:31 |
| Hobbsee | mdz: now that one, i really have no idea about... | 11:31 |
| TheMuso | I guess it depends on what the fdi files refer to, but stuff like that is in /usr/lib/hal afaiu. | 11:32 |
| cody-somerville | mdz, What graphics chipset does your T61 have? | 11:34 |
| mdz | cody-somerville: intel | 11:34 |
| mdz | 945GM | 11:35 |
| mdz | sorry, GM965 | 11:35 |
| mdz | all of my hardware info is on the bug | 11:35 |
| Hobbsee | mdz: starting point may well be /etc/acpi/thinkpad-brightness-up.sh, but that could be a red herring too. | 11:36 |
| mdz | hobbsee: that seems to be for ibm-acpi, which is for older/IBM thinkpads | 11:36 |
| mdz | lenovo ones explicitly don't use those, and use the standard acpi events instead | 11:36 |
| Hobbsee | ah | 11:36 |
| Hobbsee | well, you can certainly see if the event is getting generated... | 11:37 |
| Hobbsee | oh, which you already have. | 11:37 |
| mdz | now I wonder why I have two VID devices | 11:38 |
| mdz | one of which works and one of which doesn't | 11:38 |
| Hobbsee | one relates to actual hardware, and the other doesn't? The scripts are trying to use the one not pointed to real HW? *shrug* | 11:43 |
| mdz | hobbsee: one is for the onboard graphics, one for the mini-pcie I think | 11:45 |
| mdz | I'm going to reboot and see if I still have two on an older kernel | 11:45 |
| Hobbsee | ahhh | 11:45 |
| * Hobbsee wonders why a mini-pcie slot counts as a VID device. | 11:45 | |
| mdz | I am trying to figure this out as I go, everything I know is in the bug | 11:46 |
| persia | Hobbsee, Perhaps there's an e.g. TV out card in the miniPCIe slot? | 11:46 |
| Hobbsee | persia: possibly. | 11:47 |
| cody-somerville | what does m mean in /boot/config-<version>? | 11:50 |
| StevenK | Module | 11:51 |
| cody-somerville | So CONFIG_ACPI_VIDEO=m in there means that option is enabled? | 11:52 |
| persia | cody-somerville, It means a module is built for it, which may or may not be inserted at runtime. | 11:53 |
| persia | cody-somerville, lsmod can help determine what is actually inserted at any given time. | 11:53 |
| cody-somerville | So from http://launchpadlibrarian.net/18362442/ProcModules.txt it looks like CONFIG_VIDEO_OUTPUT_CONTROL and CONFIG_ACPI_VIDEO aren't in there? | 11:55 |
| persia | cody-somerville, From the lack of response, I suspect none of us has a handy CONFIG_* -> module name mapping. Maybe? | 12:05 |
| cjwatson | you need to look in the relevant Makefile for that | 12:05 |
| mdz | starting to look like a gnome-power-manager issue | 12:10 |
| cody-somerville | mdz, Does adding http://pastebin.ubuntu.com/55573/ to /usr/share/hal/fdi/information/10freedesktop/10-laptop-panel-hardware.fdi fix your problem? | 12:20 |
| ogra | isnt that gone upstream already ? | 12:20 |
| mdz | cody-somerville: no change | 12:22 |
| mdz | I just noticed this: | 12:22 |
| mdz | <match key="linux.sysfs_path" contains="/sys/devices/virtual/backlight/acpi_video"> | 12:22 |
| mdz | <merge key="laptop_panel.brightness_in_hardware" type="bool">false</merge> | 12:22 |
| mdz | </match> | 12:22 |
| mdz | but I have /sys/devices/virtual/backlight/acpi_video[01], not acpi_video | 12:22 |
| mdz | toggling that doesn't fix it though | 12:23 |
| mdz | laptop_panel.brightness_in_hardware = true (bool) | 12:23 |
| mdz | cody-somerville: I'm already getting this by default: | 12:24 |
| mdz | laptop_panel.brightness_in_hardware = false (bool) | 12:24 |
| mdz | which I believe is correct | 12:24 |
| mdz | cody-somerville: what do you see in g-p-m --verbose when you use your brightness keys? | 12:26 |
| mdz | cody-somerville: and lshal -m? | 12:28 |
| mdz | I get nothing in either | 12:28 |
| cody-somerville | mdz, Nothing is written. | 12:28 |
| mdz | cody-somerville: but it works? | 12:28 |
| cody-somerville | On my laptop on Hardy, yes. | 12:29 |
| ogra | mdz, <match key="linux.sysfs_path" contains="/sys/devices/virtual/backlight/acpi_video"> matches all that contains that path, so also acpi_video[01] | 12:29 |
| mdz | this used to work for me, too, and I can't work out where it's broken | 12:31 |
| ogra | hardy used only half of hal for thinkpads ... the other half was hotkeysetup | 12:31 |
| mdz | ogra: ah, of course | 12:31 |
| mdz | cody-somerville: does sudo acpi_fakekey 224 change your brightness? | 12:31 |
| cody-somerville | Not on my Aspire, no. | 12:32 |
| mdz | https://bugs.edge.launchpad.net/ubuntu/+source/hal/+bug/267682/comments/86 | 12:33 |
| ubottu | Launchpad bug 267682 in hal "Hotkeys no longer working in Intrepid on Thinkpads" [Critical,Fix released] | 12:33 |
| cody-somerville | mdz, http://www.nabble.com/T61-Brightness-keys-with-2.6.26-not-working-(NVIDIA)-td18577619.html seems to indicate that enabling CONFIG_VIDEO_OUTPUT_CONTROL and CONFIG_ACPI_VIDEO results in both brightness keys create proper acpi / key events AND change the brightness in both X and console. I assume you've already verified that those options are enabled in your kernel build? | 12:34 |
| mdz | cody-somerville: they are; that's just video.ko which is loaded and working | 12:35 |
| mdz | so that person's problem seems to have been a simpler one (no acpi video support) | 12:38 |
| cody-somerville | mdz, `echo down > /proc/acpi/ibm/brightness` decreases your screen brightness, right? | 12:39 |
| mdz | cody-somerville: no, I don't have that file. that's for older thinkpads where brightness is handled by firmware | 12:39 |
| mdz | I have this: | 12:40 |
| mdz | [ 20.635444] thinkpad_acpi: Lenovo BIOS switched to ACPI backlight control mode | 12:40 |
| mdz | [ 20.635446] thinkpad_acpi: standard ACPI backlight interface available, not loading native one... | 12:40 |
| mdz | cody-somerville: and writing 0-100 to /proc/acpi/video/VID1/LCD0/brightness changes the brightness | 12:40 |
| mdz | cody-somerville: the brightness applet does work | 12:41 |
| mdz | pitti: this is starting to look like a hal issue; do you have any ideas? (bug 280646) | 12:45 |
| ubottu | Launchpad bug 280646 in hal "ACPI brightness events no longer work on ThinkPad T61" [Undecided,New] https://launchpad.net/bugs/280646 | 12:45 |
| ogra | smells like hal or gpm wasnt properly prted here ... note that it doesnt use /proc for anything anymore so i'd suspect the proper sysfs translation is missing | 12:46 |
| ogra | *ported | 12:46 |
| cody-somerville | mdz, is http://www.klabs.be/~fpiat/linux/debian/Etch_on_Thinkpad_T61.html referring to the old setup or new setup? | 12:46 |
| ogra | etch is as old as edgy | 12:46 |
| cody-somerville | mdz, That page reports the issue is fixed in Lenny (and the Lenny page says the brightness stuff just works) | 12:47 |
| ogra | lenny is somehow like hardy with some intrepid bits, so that might be intersting, though lenny still makes full use of acpi-support etc | 12:47 |
| mdz | cody-somerville: they're running an older BIOS on that page | 12:48 |
| mdz | by about 9 months. could be that theirs works differently | 12:48 |
| * ogra thinks its hard to compare debian and ubuntu wrt power management | 12:48 | |
| ogra | there must be a sysfs path equivalent to /proc/acpi/video/VID1/LCD0/brightness | 12:50 |
| ogra | that *should* be what gpm/hal uses | 12:50 |
| kagou | tkamppeter, is there a way to auto-detect shared network printer (here, a printer server box, sharing 2 printers by lpd) ? | 12:50 |
| mdz | ogra: isn't that what /sys/devices/virtual/backlight/acpi_video is? | 12:51 |
| ogra | no idea, i have no IBM hw here, does it do what you expect on console ? | 12:52 |
| mdz | /actual_brightness there gets changed when I press the keys | 12:52 |
| mdz | but the display brightness doesn't change | 12:52 |
| cody-somerville | mdz, did you say that you have more than one laptop_panel device? | 12:53 |
| mdz | cody-somerville: yes | 12:53 |
| ogra | can you echo any values or "up/down" into any of the sub files to make it work ? | 12:54 |
| ogra | like you cn do with /proc/acpi/video/VID1/LCD0/brightness | 12:54 |
| ogra | iirc the change that gpm and hal completely ignore /proc only came with intrepid | 12:54 |
| cody-somerville | mdz, Will you try blacklisting video in /etc/modprobe.d/blacklist and rebooting and seeing if that fixes the two laptop_panel device issue? | 12:55 |
| ogra | so hardy might have had a mishmash reading from /sys and writing to /proc | 12:55 |
| mdz | ogra: yes, acpi_video1 | 12:55 |
| ogra | hm, if you change the above mentioned .fdi to match acpi_video1 instead of acpi_video, does it work ? | 12:56 |
| mdz | ogra: (acpi_video0/brightness does nothing) | 12:56 |
| mdz | ogra: as you pointed out, that would be a no-op | 12:56 |
| ogra | probably the "contains" stuff isnt working right | 12:56 |
| ogra | though i wouldnt understand why unless hal's matching is broken | 12:57 |
| mdz | ogra: it's working fine, that value is set to false in lshal | 12:57 |
| mdz | laptop_panel.brightness_in_hardware = false (bool) | 12:57 |
| ogra | ah, k | 12:57 |
| ogra | but apparetnly gpm/hal isnt using acpi_video1 as its target for value writing ... | 12:59 |
| cody-somerville | blacklisting video should leave you with only one | 13:03 |
| * ogra has to attend the mobile meeting now ... will be a bit distracted | 13:04 | |
| ogra | http://www.mail-archive.com/ibm-acpi-devel@lists.sourceforge.net/msg01097.html is a thread on ibm-acpi-devel discussing that | 13:05 |
| === thegodfather is now known as fabbione | ||
| ogra | according to that thread its a kernel issue | 13:09 |
| pitti | mdz: looking | 13:09 |
| pitti | mdz: when did that stop working, just a few days ago, or together with -evdev? | 13:13 |
| pitti | mvo: is bug 19021 on track for the release? | 13:38 |
| ubottu | Launchpad bug 19021 in synaptic "Should run dpkg --configure -a automatically" [Medium,Triaged] https://launchpad.net/bugs/19021 | 13:38 |
| pitti | mvo: (you didn't mention it in your milestone list) | 13:38 |
| pitti | mvo: oh, not RC, nevermind | 13:38 |
| === mterry_ is now known as mterry | ||
| pitti | ogra: please upload the hardy SRU fixes for bug 258110 to intrepid ASAP | 13:42 |
| ubottu | Launchpad bug 258110 in cmpc "Camera application cannot record video" [Critical,In progress] https://launchpad.net/bugs/258110 | 13:42 |
| pitti | mvo: bug 257947 is fix released upstream, does it mean it's fixed by the load of compiz packages you just uploaded? (if so, then the bug wasn't auto-closed for some reason) | 13:44 |
| ubottu | Launchpad bug 257947 in firefox-3.0 "After install of 8.10 alpha 4 Firefox opens with tool bar under top panel." [Undecided,Confirmed] https://launchpad.net/bugs/257947 | 13:44 |
| ogra | pitti, they are in intrepid ... they are upstream | 13:44 |
| pitti | ogra: oh, can you please close the intrepid tasks then and say so in the bug? thanks | 13:44 |
| ogra | will do | 13:45 |
| ogra | the fixes are both backports from newer upstream :) | 13:45 |
| mvo | pitti: dpkg --configure -a is not cirticial, I think it should be postponed | 13:47 |
| mvo | pitti: the compiz fix must be imported as a patch (its small) I will do that soonish | 13:47 |
| pitti | mvo: ah, it was post 0.7.8? | 13:48 |
| mvo | pitti: yes | 13:48 |
| pitti | mvo: likely to land this week? | 13:48 |
| mvo | pitti: yes | 13:48 |
| * pitti hugs mvo, thansk | 13:49 | |
| mvo | chhers | 13:49 |
| kagou | hi pitti :) do you know if our cups version support the MAC Rendezvous ? | 13:49 |
| pitti | kagou: you mean bonjour? yes, it does for discovery | 13:49 |
| pitti | mvo: bug 278112 seems harder, not even reproducible by you? | 13:50 |
| ubottu | Launchpad bug 278112 in compiz "Screensaver doesn't start" [Medium,In progress] https://launchpad.net/bugs/278112 | 13:50 |
| kagou | pitti, indeed :) Thanks ! So i will check that more carefully | 13:50 |
| * ogra can reproduce | 13:50 | |
| ogra | but has no cue where to look deeper | 13:50 |
| ogra | *clue | 13:50 |
| pitti | kagou: you have to enable it in BrowseProtocols | 13:53 |
| kagou | mmmh ok pitti , it's de-activated | 13:55 |
| mvo | pitti: yes, the screensaver one is more difficult, I was able to reproduce it on a test-system but for me 0.7.8 fixed it, I will try on a different machine (with a different driver) | 13:57 |
| pitti | ogra: does 0.7.8 fix it for you as well? | 13:57 |
| ogra | pitti, i havent upgraded the samsung yet, lets see | 13:58 |
| tkamppeter | kagou: "BrowseProtocols cups dnssd" in cupsd.conf makes CUPS broadcasting with both IPP (for Linux/unix clients) and DNS-SD/Bonjour (for Mac OS X clients). | 13:59 |
| ogra | geeez ! | 13:59 |
| * ogra sees scrollkeeper going away | 13:59 | |
| ogra | \o/ | 13:59 |
| kagou | tkamppeter, the default protocol (if not specified) is cups ? | 14:01 |
| kagou | tkamppeter, seen in http://www.cups.org/documentation.php/ref-cupsd-conf.html#BrowseRemoteProtocols : | 14:01 |
| kagou | The default protocol is CUPS dnssd for BrowseLocalProtocols and for BrowseRemoteProtocols | 14:02 |
| tkamppeter | kagou, yes. This is CUPS' standard IPP broadcasting. | 14:02 |
| kagou | tkamppeter, ok. Do I need to had additional package for dnssd support on cups server ? | 14:03 |
| kagou | tkamppeter, ok. Do I need to add additional package for dnssd support on cups server ? | 14:03 |
| jmichel | I am creating an Ubuntu package with dpkg-buildpackage... it seems that after I called dpkg-buildpackage once and get an error, I cannot modify any files afterwards | 14:03 |
| tkamppeter | kagou, AFAIK not | 14:03 |
| cjwatson | jmichel: that's not normal. what happens when you try to modify those files? | 14:04 |
| jmichel | Actially, I can modify files but changes are not taken into account | 14:04 |
| cjwatson | jmichel: does the package use a patch system? look in debian/patches/ | 14:04 |
| kagou | thanks tkamppeter, so I have a problem here. I will investigate it before report it | 14:05 |
| jmichel | cjwatson: there is no debian/patches | 14:05 |
| jmichel | cjwatson: It seems I need to change version in configure.ac to get my changes to be considered | 14:05 |
| jmichel | I thought dpkg-builpackage was keeping a version of my files somewhere but I cannot find where? | 14:07 |
| jmichel | Lets say I build a software "app-4.0" with dpkg-builpackage in a tmp folder, then I erase everything from the tmp folder, then do some changes in the Makefile.am and recopy my new version of "app-4.0"... dpkg-builpackage will still use the old Makefile.ac that is not even in my project anymore!?! | 14:11 |
| jmichel | sorry Makefile.am | 14:12 |
| jmichel | But from where does that old file comes from? | 14:12 |
| jmichel | Then if I just rename my folder "app-4.0.1" and change version in configure.ac to 4.0.1 it will instantly start to use my changes | 14:14 |
| kagou | tkamppeter, so, after installation of bonjour in a windows box to verify that it can see bjour shared printers I : 1/ added "BrowseProtocols cups dnssd" in /etc/cups/cupsd.conf 2/ restart cups | 14:14 |
| kagou | but s-c-p do not show bonjour printers, and I don't see usefull informations in cups access/error logs | 14:15 |
| jmichel | Could someone just give me a hint about what is this feature and if I can delete the file "cache ?" create by dpkg-builpackage | 14:15 |
| kagou | any ideas to investigate this problem ? | 14:15 |
| kagou | tkamppeter, just for information : s-c-p is the default printer tool in mandriva 2009 :) | 14:17 |
| tkamppeter | kagou, great to hear that. | 14:30 |
| tkamppeter | kagou for s-c-p to show Bonjour printers in the New Printer wizard one of the backends needs to detect them. The backend for that is /usr/lib/cups/backend/dnssd, and this backend needs avahi-utils to work. | 14:32 |
| kagou | ok tkamppeter. avahi-utils is installed. But using it, "avahi-browse -a" do not report bonjour printers | 14:38 |
| kagou | so cups seems to be innocent ^^ | 14:38 |
| cjwatson | jmichel: dpkg-buildpackage doesn't keep any kind of cache, believe me. I've no idea what your problem is | 14:39 |
| cjwatson | jmichel: perhaps you could post a tarball of your working directory and instructions on how to reproduce the problem | 14:40 |
| kagou | thanks pitti and tkamppeter. I'v reported the bug on avahi #280754 | 14:54 |
| kagou | https://bugs.edge.launchpad.net/ubuntu/+source/avahi/+bug/280754 | 14:54 |
| ubottu | Launchpad bug 280754 in avahi "Can't find bonjour printers" [Undecided,New] | 14:54 |
| jmichel | cjwatson: I think my solution was only to delete the .dsc file and the tar.gz file from the upper folder prior to restart the build | 14:54 |
| cjwatson | jmichel: still doesn't make sense though, unless you're invoking dpkg-buildpackage in a bizarre way or the package is doing something crazy | 14:55 |
| seb128 | kagou: ps ax | grep avahi? | 14:55 |
| cjwatson | to build a binary package from a source tree, you would normally use 'dpkg-buildpackage -b -rfakeroot' (or just 'debuild -b') | 14:55 |
| kagou | seb128, avahi-daemon is running | 14:55 |
| seb128 | kagou: the exact line? | 14:55 |
| seb128 | kagou: that's the status which interests me there | 14:56 |
| kagou | avahi-daemon: running [satori.local] | 14:56 |
| seb128 | ok, running, so that's a different bug that the one I was having | 14:56 |
| jmichel | cjwatson: I was not using -b so does it try to build source + binary ? | 14:56 |
| elmo | can we make -rfakeroot the default of dpkg-buildpackage when run as a normal user? | 14:57 |
| cjwatson | jmichel: yes, although even then it wouldn't unpack the old source package again | 14:57 |
| wgrant | elmo: It is. | 14:57 |
| wgrant | At least in Intrepid. | 14:57 |
| wgrant | Maybe in Hardy too. I forget. | 14:57 |
| kagou_ | seb128, avahi 7434 0.0 0.0 2888 1500 ? Ss 15:45 0:00 avahi-daemon: running [satori.local] | 14:58 |
| kagou_ | avahi 7435 0.0 0.0 2888 496 ? Ss 15:45 0:00 avahi-daemon: chroot helper | 14:58 |
| cjwatson | wgrant: so it is - dpkg 1.14.7, so >=hardy | 14:58 |
| * cjwatson has some very old habits | 14:58 | |
| seb128 | kagou_: <seb128> ok, running, so that's a different bug that the one I was having | 14:58 |
| elmo | yay, so it is | 14:58 |
| wgrant | cjwatson: I still do it too. | 14:58 |
| wgrant | But whenever anybody brings it up in channel I remember that it's the default now. | 14:59 |
| wgrant | And remind myself not to forget it next time. | 14:59 |
| wgrant | But I inevitably do. | 14:59 |
| elmo | ok, how about making dpkg-dev depend/recommend on fakeroot? :-P | 14:59 |
| cjwatson | I'm currently trying to get over explicitly specifying compression (-z or -j) when uncompressing files with tar | 14:59 |
| wgrant | Recommend sounds good. | 14:59 |
| jmichel | cjwatson: thanks for your help... I will try to reproduce the problem and post something more specific... | 15:00 |
| wgrant | cjwatson: When did that change!? | 15:00 |
| ogra | wgrant, while i see you here, to swtich off synaptics you just need to unset input.x11_driver with hal-set-property for the udi of the touchpad | 15:00 |
| persia | -z -j is optional now? | 15:00 |
| elmo | yes | 15:01 |
| wgrant | ogra: Will that work at runtime? | 15:01 |
| ogra | wgrant, not sure why you say it doesnt work | 15:01 |
| ogra | sure | 15:01 |
| wgrant | ogra: Also, that's not quite what syndaemon does. | 15:01 |
| ogra | its hal :) | 15:01 |
| cjwatson | wgrant: tar 1.15, apparently - 2004 | 15:01 |
| * wgrant rereads the thread. | 15:01 | |
| cjwatson | * Compressed archives are recognised automatically, it is no longer | 15:01 |
| cjwatson | necessary to specify -Z, -z, or -j options to read them. Thus, you can | 15:01 |
| cjwatson | now run `tar tf archive.tar.gz'. | 15:01 |
| wgrant | cjwatson: Arrrrgh. | 15:01 |
| ogra | wgrant, i'm not sure though that it will work properly for re-enabling without setting all options again manually, but essentially thats what i would do | 15:02 |
| ogra | and you could just read the .fdi to re-enable the options | 15:02 |
| elmo | reported dpkg-dev/fakeroot as #280758 | 15:02 |
| wgrant | ogra: I suspect it's somewhat nicer to use the XInput property, rather than removing the device... | 15:02 |
| ogra | requires some coding though | 15:02 |
| wgrant | elmo: I suspect it should recommend, yes. | 15:02 |
| wgrant | ogra: syndaemon needs to do it whenever typing occurs - vanishing the device sounds expensive and overkill. | 15:03 |
| ogra | wgrant, well, hal is used for everything nowadays, why go back to old stuff ? | 15:03 |
| wgrant | ogra: XInput properties were just backported to Xserver 1.5... they're brand new. | 15:03 |
| ogra | wgrant, i thought more about a checkbox in the touchpad props to disable it completely | 15:03 |
| wgrant | ogra: There's one there now. | 15:03 |
| ogra | ah, yeah | 15:04 |
| wgrant | I know, because I wrote that bit of code and am fixing it for the new property API right now. | 15:04 |
| * ogra didnt look at that capplet for ages | 15:04 | |
| wgrant | Heh. | 15:04 |
| ogra | but still i dont see a reason to run a separate daemon if you have hal | 15:04 |
| jcristau | i don't think fiddling with hal would work at runtime anyway | 15:04 |
| ogra | jcristau, it works fine for touchscreen calibration | 15:05 |
| wgrant | jcristau: Perhaps unsetting the driver would work, but I doubt setting the other properties would. | 15:05 |
| wgrant | Hmmm. | 15:05 |
| ogra | where you have to set the calibrate property on and off | 15:05 |
| ogra | wgrant, sure, you can just iterate over the options with hal-set-property | 15:05 |
| wgrant | ogra: Does the driver really respect that? | 15:05 |
| ogra | afaik thats what is done anyway on hal startup, should work at runtime as well | 15:06 |
| jcristau | ogra: you can do that, and X won't care | 15:06 |
| wgrant | It seems a bit odd that we've finally grown two independent methods of setting runtime properties within 6 months of each other | 15:06 |
| ogra | jcristau, it *works* with evtouch :) | 15:06 |
| jcristau | weird.. | 15:06 |
| ogra | afaik its the whole purpose of using hal that you can change configs at runtime | 15:06 |
| ScottK | pitti: I'd like to see someone involved in breaking kdebluetooth step up to help fix the problem. | 15:07 |
| seb128 | did anybody look if fedora has a patch? | 15:08 |
| seb128 | they have the new bluez for some time now | 15:08 |
| ScottK | I didn't know that. I'll look. | 15:08 |
| seb128 | they did the change before ubuntu and several of the patches which have been used are fedora changes | 15:08 |
| dholbach | seb128: http://daniel.holba.ch/harvest/handler.py?pkg=kdebluetooth | 15:08 |
| ogra | jcristau, http://paste.ubuntu.com/55658/ | 15:08 |
| ogra | jcristau, thats the wrapper i use for ev_calibrate ... works just fine | 15:09 |
| pitti | http://daniel.holba.ch/harvest/handler.py?pkg=kdebluetooth doesn't look very relevant, though | 15:09 |
| jcristau | ogra: that's not 'at runtime', you start another X server :) | 15:09 |
| seb128 | dholbach: I'm not the one looking for changes and I know where to look for fedora changes but thank you ;-) | 15:09 |
| dholbach | *nod* | 15:09 |
| ogra | jcristau, for the calibration tool, the setting applies to the running server | 15:09 |
| ogra | you cant calibrate at the rinning display sadly | 15:10 |
| tjaalton | ogra: the hal settings are used only when the xserver starts | 15:10 |
| ogra | i'll work with soren hauberg for jaunty to fix that stuff | 15:10 |
| ScottK | seb128: They still have the KDE3 version of kdebluetooth. | 15:10 |
| tjaalton | not runtime, for that there is properties now | 15:10 |
| wgrant | tjaalton: That's what I thought - thanks for confirming. | 15:10 |
| jcristau | ogra: the hal settings apply to the server where you start evcalibrate | 15:10 |
| ogra | tjaalton, then i wonder why it works | 15:10 |
| ogra | hmm | 15:10 |
| jcristau | ogra: then presumably evcalibrate talks to the device driver somehow | 15:11 |
| jcristau | and *that* applies to the running x server | 15:11 |
| ScottK | Actually no. I think they have both. | 15:11 |
| ogra | yes, in raw mode | 15:11 |
| ogra | but only if calibrate is set to true | 15:11 |
| ogra | jcristau, hmm, you might be right | 15:11 |
| ogra | evcalibrate only writes to /etc/evtouch/config btw, which then gets iterated over by hal-set-property ... | 15:13 |
| jcristau | ok.. i have no clue about evtouch. | 15:15 |
| ogra | i patched it a lot :) so it works at all after four years | 15:15 |
| * ogra thinks nobody in debian or ubuntu ever tried to actually use it :) | 15:16 | |
| ogra | but soren seems to work on a cairo based calibration tool and tries to unify all touchscreen drivers into using evdev, so thats an interim solution anyway | 15:17 |
| wgrant | Um, any idea why gdb is segfaulting? How is one meant to debug that sort of thing? | 15:18 |
| ogra | with the new mobile images we just gained a big tester community for such stuff so touchscreen support should rule in jaunty timeframe :) | 15:18 |
| persia | wgrant, Generate a core file, and then hope gdb doesn't segfault when processing it? | 15:18 |
| * wgrant hopes to make touchpad support rule similarly. | 15:18 | |
| wgrant | persia: It segfaults when run even with no args. I might reboot once this build finishes. | 15:19 |
| persia | wgrant, Which gdb, which arch? | 15:19 |
| ogra | wgrant, easy, you get enough test reports :) touchscreens werent really widely used unti now | 15:19 |
| wgrant | persia: 6.8-3ubuntu2, intrepid/i386. | 15:20 |
| wgrant | ogra: True. But some touchpads are very, very strange. | 15:20 |
| ogra | yeah | 15:20 |
| wgrant | Hopefully the autoscaling in master will fix most cases of that. | 15:20 |
| doko | ubuntu-archive: when the openjdk-6 upload hits binary NEW, please move the openjdk-6-source-files package into main, and the icedtea6-plugin package into universe | 15:20 |
| persia | wgrant, Try downgrading to 6.8-3ubuntu1, and use that to troubleshoot the 6.8-3ubuntu2 binary? | 15:22 |
| wgrant | persia: I'll try that once the build finishes. Thanks. | 15:22 |
| mdz | pitti: it stopped working a while ago, around the same time as evdev (I had assumed it was the same bug) | 15:22 |
| wgrant | ogra: Anyway, back to syndaemon... syndaemon doesn't exist just to allow people to turn the touchpad off - it will watch for key presses and turn the touchpad off while they are occurring, so HAL can't do it. | 15:25 |
| persia | wgrant, How is "keypress" defined? I've a device with a touchscreen next to a touchpad, and the touchpad is where the palm would rest for stylus use. | 15:27 |
| wgrant | persia: It checks for any differences in the keymap state. | 15:29 |
| wgrant | This can of course be easily altered, and I ended up rewriting most of it today anyway. | 15:29 |
| persia | Ah, that's fairly flexible, but not quite enough to cover this fairly irregular case. Perhaps you'd have some time at UDS to look at it, and see what might make sense? | 15:31 |
| wgrant | Sure. That's only a small bit of the code. | 15:31 |
| wgrant | Users also seem to want to be able tell something to disable the touchpad when they have an external mouse plugged in. We can't accommodate everything, but it would be nice and probably not unthinkably difficult to cover the common cases. | 15:33 |
| ScottK | seb128: No. No relevant patches in Fedora. | 15:33 |
| seb128 | ok, that was worth looking | 15:34 |
| ogra | wgrant, yeah, might make sense | 15:34 |
| wgrant | ogra: Which bit? | 15:35 |
| persia | wgrant, That's hard. I can imagine a device with a USB-connected "mouse" of some sort as well as a touchpad, where the user would want both to work. | 15:35 |
| wgrant | persia: Yes, it is difficult. It needs some thought. | 15:36 |
| ogra | wgrant, the monitoring of kbd events | 15:37 |
| wgrant | ogra: It's not great, but it has been that way since at least 2004, and users seem to like it. | 15:38 |
| * ogra would still prefer hal being able to handle it on the fly :) | 15:39 | |
| wgrant | Why is it hal's business? | 15:39 |
| ogra | but since thats apparently not working ... | 15:39 |
| ogra | because hal handles the devce and its options | 15:39 |
| wgrant | hal should be abstracting my hardware, not handling complex logic like that. | 15:39 |
| ogra | *both* devices actually | 15:39 |
| wgrant | hal handles the device and its initial options. | 15:39 |
| ogra | right, and it should also handle option changes on the fly | 15:40 |
| wgrant | XInput device properties are the better way to set things at runtime - but they unfortunately don't persist. | 15:40 |
| wgrant | It would have to be redesigned. | 15:40 |
| ogra | it is redesigned atm :) | 15:40 |
| ogra | being called devicekit | 15:40 |
| wgrant | I haven't heard much about that effort lately. | 15:40 |
| ogra | hal's original author (davidz) is working fulltime on devicekit atm | 15:41 |
| ogra | together with the move of dbus in the kernel you should have a lot more opportunities to adjust HW settings on the fly | 15:42 |
| tjaalton | that would basically mean that devicekit should know about how to change X input device properties.. not likely to happen | 15:42 |
| wgrant | Perhaps the xorg.conf-style options should go away and DeviceKit should use XInput properties instead. | 15:42 |
| wgrant | tjaalton: Why not? | 15:42 |
| tjaalton | wgrant: just a thought | 15:42 |
| ogra | tjaalton, i think david has that in mind | 15:43 |
| === BenC1 is now known as BenC | ||
| tjaalton | ogra: ok, in that case I'll shut up :) | 15:43 |
| wgrant | That would be an excellent solution, IMO. | 15:43 |
| ogra | hal wasnt designed as a config tool, thats what devicekit will do afaik | 15:43 |
| tjaalton | k, so g-s-d and the kde equivalent wouldn't have to duplicate efforts | 15:44 |
| wgrant | That would really clean up some of the mess that we have with input device config. | 15:44 |
| ogra | g-s-d ? | 15:44 |
| tjaalton | gnome-settings-daemon | 15:44 |
| ogra | thats used for the session | 15:44 |
| ogra | gtk options and the like | 15:44 |
| tjaalton | yes | 15:44 |
| ogra | i dont think a HW handling tool can ever replace it | 15:45 |
| wgrant | And for configging all of your X devices. | 15:45 |
| ogra | right, these peieces should be in hal already :) | 15:45 |
| wgrant | At the moment it talks directly to X for setting mouse and keyboard properties. | 15:45 |
| wgrant | They can't be. | 15:45 |
| tjaalton | ogra: I meant the properties stuff, not general session things | 15:45 |
| wgrant | Yet. | 15:45 |
| ogra | right, thats what devicekit might/should solve | 15:45 |
| wgrant | (in this case properties doesn't just mean the new XI device properties) | 15:45 |
| ogra | on a low level | 15:45 |
| wgrant | As long as there's a way for user apps to make changes to the running config... | 15:46 |
| ogra | so your session doesnt need to care, apart from providing guis for it | 15:46 |
| ogra | which will happen through dbus calls | 15:46 |
| wgrant | Right. Makes sense. | 15:46 |
| ogra | handled through consolekit/ploicykit ACLs | 15:46 |
| jcristau | something still needs to happen through X11.. | 15:47 |
| ogra | pfft X11 :) | 15:47 |
| ogra | modprobe xorg :) | 15:47 |
| ogra | mvo, 0.7.8 seems to not fix it for me | 15:50 |
| ogra | though i still think its xorgs/the intel dirvers fault of not handling dpms right | 15:51 |
| ogra | mvo, oh, i didnt get .8 in my upgrade, sorry, still 0.7.7 here | 15:55 |
| pitti | mdz: ok, so it wasn't the recent hal-info upload; so the thinkpad_acpi fdi hack didn't cover this, although the kmod is resonsible for setting the brightness as well? | 15:57 |
| ogra | slangasek, what about the removal of uswsup ? i still see it in my daily images, wasnt it supposed to be removed from the archive ? | 15:58 |
| mvo | ogra: yeah, I'm waiting for the publisher | 15:58 |
| * ogra joins the waiting ... lines up at the bus stop :) | 15:58 | |
| === persia_ is now known as persia | ||
| nxvl | asac: hi! is there a wiki or something on how to patch firefox? | 16:12 |
| ScottK | nxvl: Try #ubuntu-mozillateam | 16:12 |
| asac | nxvl: -> #ubuntu-mozillateam | 16:12 |
| * ScottK high fives asac. | 16:13 | |
| nxvl | thank you! | 16:13 |
| mvo | ogra: plugins-main is done, plugins-extra is still pending | 16:13 |
| ogra | yay | 16:13 |
| * asac high tens ScottK ;) | 16:14 | |
| asac | hehe | 16:14 |
| === bddebian2 is now known as bddebian | ||
| === ember_ is now known as ember | ||
| mdz | pitti: sorry, have been on the phone all afternoon. off now. | 16:43 |
| mdz | pitti: I'm not entirely sure how it's supposed to work | 16:43 |
| kirkland | BenC: ping | 16:43 |
| mdz | pitti: there is an ACPI event generated, and hal is receiving that (but not generating an event) | 16:44 |
| kirkland | BenC: dendrobates has assigned me https://bugs.launchpad.net/bugs/257739, in soren's absence | 16:44 |
| ubottu | Launchpad bug 257739 in linux "intrepid guest install with virtio net doesn't work" [Critical,Confirmed] | 16:44 |
| mdz | pitti: there is also an X keysym event being generated, and I can see that with xev, but nothing reacts to it | 16:44 |
| kirkland | BenC: in that bug, cjwatson posted a conversation between he and soren, the net of which was that soren need to talk to you (or the kernel team) about the virtio drivers | 16:44 |
| theBishop | was leaving "Message Notification" in Pidgin Off by default a conscious development decision? If so, I think it was a terrible idea. | 16:45 |
| mdz | pitti: I see the values change in sysfs, but the brightness doesn't actually change. it DOES change if I write to one of the two sysfs acpi_video devices | 16:45 |
| kirkland | BenC: I'm trying to determine if that conversation took place, and if anything came of it? | 16:45 |
| cjwatson | BenC: basically I felt that the block and net bits of virtio-modules should be folded into block-modules and nic-modules | 16:45 |
| cjwatson | BenC: which would save a lot of d-i-side juggling | 16:45 |
| BenC | cjwatson, kirkland: I was sure soren posted updates for that to kernel-team@ and that we had integrated it | 16:47 |
| cjwatson | aha, I didn't see that | 16:48 |
| cjwatson | let me check | 16:48 |
| cjwatson | virtio_blk and virtio_net are still in virtio-modules | 16:48 |
| cjwatson | virtio_net is in nic-modules (duplicating virtio-modules, which is a bug), which may solve the network part | 16:49 |
| cjwatson | it still doesn't really look quite right | 16:49 |
| kirkland | cjwatson: BenC: for what it's worth, the storage part looks to be a regression between Beta and today. ie, the beta iso detects the vda disk, and today's iso does not | 16:53 |
| cjwatson | liw: how are things looking with lool's comments on system-cleaner for main (279554)? | 16:54 |
| kirkland | BenC: is there more to be done on my side, or am i just waiting for kernel-team@ to take soren's changes? | 17:03 |
| BenC | kirkland: Can you find the changes, make sure the still apply, and forward them to me directly? | 17:04 |
| kirkland | BenC: i'll track them down | 17:05 |
| BenC | kirkland: thanks | 17:07 |
| kirkland | BenC: actually, the only thing I've seen from Soren recently on kernel-team@ is https://lists.ubuntu.com/archives/kernel-team/2008-August/002892.html | 17:09 |
| kirkland | BenC: which looks unrelated | 17:09 |
| BenC | kirkland: Hmm...ok, if you know all the changes that need to happen, can you pop out a diff? | 17:10 |
| kirkland | BenC: i don't know all the changes, as I'm still coming up to speed as soren's backup on this, but i'm working on it | 17:11 |
| kirkland | BenC: most immediately, i notice that this is a regression since the beta iso came out | 17:11 |
| kirkland | BenC: ie, the beta iso server installer autodetects a virtio disk, and today's does not | 17:12 |
| kirkland | BenC: i'm hoping that that's something simple to track down | 17:12 |
| BenC | kirkland: any changes in that regard in our packaging? | 17:12 |
| kirkland | BenC: our = kernel? | 17:12 |
| cjwatson | that's bizarre, let me see if I can find history | 17:12 |
| BenC | kirkland: right | 17:12 |
| kirkland | 2.6.27-4 vs 2.6.27-6 | 17:15 |
| * cjwatson fishes down the relevant udebs | 17:15 | |
| cjwatson | ok, the kernel udeb layout is essentially the same | 17:15 |
| * cjwatson <- very confused | 17:16 | |
| kirkland | cjwatson: i'm handling virtio network and virtio hard disk as separate problems at the moment | 17:17 |
| cjwatson | oho! | 17:17 |
| cjwatson | somebody unfixed the virtio-modules priority change I did | 17:17 |
| kirkland | cjwatson: i found the no-disk-detected very easy to reproduce | 17:17 |
| cjwatson | BenC: for the short term, could you make virtio-modules Priority: standard? that's why it regressed | 17:17 |
| cjwatson | I'd changed the overrides in the archive, but that didn't get preserved across ABI changes | 17:18 |
| cjwatson | I'll fix it again now | 17:18 |
| cjwatson | kirkland: ^- I think that should fix both of them | 17:18 |
| kirkland | cjwatson: very nice, thanks | 17:18 |
| BenC | kirkland: done in the kernel as well | 17:19 |
| cjwatson | thanks! | 17:19 |
| kirkland | cjwatson: any chance we can turn the crank on the server iso build? | 17:19 |
| cjwatson | I'll look at the udeb layout | 17:19 |
| cjwatson | kirkland: needs a publisher run first | 17:19 |
| kirkland | cjwatson: okey doke | 17:19 |
| cjwatson | so at least two hours now :( | 17:19 |
| kirkland | cjwatson: i was about to buzz off to lunch | 17:19 |
| kirkland | cjwatson: that's okay, i still have many hours left in my work day ;-) | 17:19 |
| kirkland | cjwatson: i would very much appreciate being able to crank through another round of testing this afternoon, if at all possible | 17:20 |
| kirkland | BenC: thanks, man | 17:20 |
| BenC | kirkland: np | 17:20 |
| cjwatson | BenC: I think it's something like http://paste.ubuntu.com/55700/ | 17:20 |
| cjwatson | but I should probably test-build that | 17:20 |
| cjwatson | test-building on ronne now | 17:23 |
| BenC | cjwatson: that's the patch I was thinking of, thanks | 17:26 |
| ion_ | Any pointers about how to debug LP #278188? Thanks. | 17:31 |
| ubottu | Launchpad bug 278188 in linux "irda broken on Thinkpad T23 with 2.6.27-4-generic, works with 2.6.24-16-generic" [Undecided,New] https://launchpad.net/bugs/278188 | 17:31 |
| cjwatson | BenC: I just knocked that together a few minutes ago, although soren might have produced the same thing :) | 17:35 |
| === beuno is now known as beuno-lunch | ||
| BenC | cjwatson: fooled me :) | 17:42 |
| asac | soren: i think i know why nfs doesnt come up for NM | 17:53 |
| asac | soren: or did you already figure that out? | 17:54 |
| cjwatson | mvo: do you have any idea why the Apttermlog.gz in bug 269182 seems to have somebody running 'vim /boot/grub/menu.lst' by hand in the middle of it? | 17:55 |
| ubottu | Launchpad bug 269182 in grub "package linux-image-2.6.27-3-generic 2.6.27-3.4 [modified: lib/modules/2.6.27-3-generic/modules.pcimap lib/modules/2.6.27-3-generic/modules.dep lib/modules/2.6.27-3-generic/modules.alias lib/modules/2.6.27-3-generic/modules.symbols] failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/269182 | 17:55 |
| cjwatson | mvo: I noted that the failure appears right after they exit the shell and was wondering if that could be connected | 17:56 |
| mdz | bryce: ping | 17:56 |
| mvo | cjwatson: I suspect (without looking at it yet) that it might be someone using the ucf option "get a terminal" | 17:56 |
| cjwatson | mm, I suppose it must be | 17:56 |
| cjwatson | I was trying to figure out if maybe something was interfering with the fd on the X socket | 17:58 |
| mdz | pitti: we have a breakthrough in bug 280646; it is related to the gconf numlock setting | 18:00 |
| ubottu | Launchpad bug 280646 in hal "ACPI brightness events no longer work on ThinkPad T61" [Medium,Triaged] https://launchpad.net/bugs/280646 | 18:00 |
| mdz | beginning to look like an evdev issue | 18:00 |
| mvo | cjwatson: I think liw had a bug where fglrx got loaded during the upgrade and that killed (froze) his X | 18:01 |
| cjwatson | mvo: I'm not seeing anything in dmesg; it's a shame syslog isn't included in apport reports | 18:02 |
| mvo | cjwatson: the reporter has a ati card as well and had fglrx installed - but dkms failes during the install so its probably something else | 18:02 |
| NCommander | ScottK, working on amule. I got called to a massive fire last night | 18:03 |
| cjwatson | fglrx (8.522): Installing module.^M | 18:03 |
| cjwatson | .......(bad exit status: 7)^M | 18:03 |
| cjwatson | informative ;-) | 18:03 |
| mvo | cjwatson: I have seeen similar "frontend lost connected" in the past in connection with ucf, I think it was the diff feature then. but it might simply a usability problem (someone just closing the debconf dialog for example) | 18:03 |
| mvo | cjwatson: one issue that silbs ran into was that she clicked "cancel" in a debconf prompt and that makes the script fail (at least that is what I concluded from the logs) | 18:04 |
| cjwatson | well, that depends on the client | 18:04 |
| cjwatson | I don't think it's the case here | 18:05 |
| cjwatson | I've asked the reporter if they closed the terminal window, though | 18:05 |
| mvo | cjwatson: ok, that would make sense (closing the widnow) | 18:06 |
| slangasek | ogra: no, uswsusp will be dropped as a recommends: of pm-utils (soon), it's not going to be dropped from the archive | 18:06 |
| cjwatson | mvo: can we disable the close button on that window? I doubt it's a good idea to use it :) | 18:06 |
| mvo | cjwatson: I was think that too, for debconf gnome, disable close button and cancel button | 18:07 |
| cjwatson | actually, I was trying to do that for ubiquity (in its standalone mode) a while back, and couldn't find out how | 18:07 |
| cjwatson | if you happen to know, please tell me :) | 18:07 |
| mvo | cjwatson: self.window_main.window.set_functions(gtk.gdk.FUNC_MOVE) (the second window is the gdk-window) | 18:08 |
| mvo | that is what I use in update-manager | 18:08 |
| mvo | (in the release upgrader) | 18:08 |
| cjwatson | mvo: aha! thanks a lot | 18:09 |
| mvo | cjwatson: cheers, I have a look at debconf now | 18:09 |
| mdz | does anyone know how num lock works in this day and age? input layer? X? | 18:09 |
| mrxmike | all intrepid (64bit) beta releases (alternative/normal) installers crash on my system > Intel D945GLCF Atom motherboard (with atom 330 proc) | 18:10 |
| mrxmike | are you guys (devs/ canonical) aware of this? | 18:10 |
| asac | soren: ok i think i fixed it ;) | 18:11 |
| mdz | mrxmike: I don't happen to know; have you looked to see if there is a bug open? | 18:11 |
| mrxmike | mdz: not yet | 18:12 |
| mdz | if there is no bug open, then it is safe to say we are not aware | 18:12 |
| cjwatson | mrxmike: if it's consistent across all installers, it's likely to be a kernel bug, so start at https://bugs.launchpad.net/ubuntu/+source/linux | 18:12 |
| mdz | mrxmike: does the 32-bit build work? | 18:12 |
| mrxmike | mdz: havent tried yet, its 64bit.. so i wanna enjoy 64bit | 18:13 |
| mrxmike | :) | 18:13 |
| mdz | mrxmike: the intrepid desktop kernel doesn't have all of the drivers you'll want for Atom; the mobile bulids should | 18:13 |
| mrxmike | mdz: huh? | 18:13 |
| mdz | mrxmike: the folks who work with atom hang out on #ubuntu-mobile | 18:13 |
| mdz | mrxmike: I'm not familiar with that particular motherboard, but we provide a separate kernel for LPIA (Atom) | 18:14 |
| mrxmike | LPIA=? | 18:15 |
| mrxmike | low power IA? | 18:15 |
| === dholbach_ is now known as dholbach | ||
| cjwatson | yes | 18:16 |
| mrxmike | well... i would like to use this system as a server... | 18:16 |
| mrxmike | i dont think ubuntu-mobile is suitable for that? :o | 18:16 |
| mdz | mrxmike: then why are you installing ubuntu desktop? :-) | 18:17 |
| mrxmike | i tried both server and desktop | 18:17 |
| mrxmike | i didnt mention the word 'desktop' | 18:17 |
| === beuno-lunch is now known as beuno | ||
| mrxmike | :-) | 18:18 |
| ogra | slangasek, bah :( | 18:18 |
| mdz | ogra: do you know if the intrepid generic kernel works on Atom? | 18:18 |
| cjwatson | mrxmike: you mentioned alternative (by which I guess you meant alternate), which installs the Ubuntu desktop. :-) | 18:18 |
| mrxmike | i tried the normal server intrepid version | 18:19 |
| mrxmike | 64bit | 18:19 |
| mrxmike | and the alternative 64bit desktop version | 18:19 |
| ogra | mdz, yes, it does | 18:19 |
| === robbiew is now known as robbiew_ | ||
| ogra | mdz, ubuntu-mobile uses -generic by default, we have plenty atom users with mobile | 18:20 |
| cjwatson | mrxmike: even on systems capable of 64-bit operation, 32-bit is more appropriate for many uses, so it's worth trying out | 18:20 |
| mdz | ogra: oh, good. mrxmike will be pleased | 18:22 |
| mrxmike | ok, well ... the kernel (of the livecd) does start with acpi=off | 18:22 |
| mrxmike | hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm, i red over ogra's comment | 18:22 |
| mdz | ogra: who uses -lpia then? ubuntu-mid? | 18:23 |
| mrxmike | generic=unmodified= same as unbuntu desktop | 18:23 |
| mrxmike | isnt it? | 18:24 |
| pwnguin | arg | 18:25 |
| mdz | does anyone know how to track down which process is setting a particular gconf key? | 18:28 |
| ogra | mrxmike, xactly | 18:28 |
| mdz | mrxmike: depends on what you mean by "unmodified" (relative to what?) | 18:29 |
| * ogra read that as unmodified relative to desktop :) | 18:31 | |
| === bddebian2 is now known as bdddebian | ||
| === bdddebian is now known as bddebian | ||
| mrxmike | mdz: relative to what its forked of within the ubuntu stall ;P | 18:33 |
| === robbiew_ is now known as robbiew | ||
| mdz | mrxmike: parse error | 18:37 |
| mathiaz | mvo: did you get a chance to take a look at bug https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/84918 ? | 18:37 |
| ubottu | Launchpad bug 84918 in unattended-upgrades "package should set up sensible config" [High,Triaged] | 18:37 |
| bryce | mdz, sounds like some progress is made on the brightness key issue? Need something done for X? | 18:37 |
| mdz | bryce: that's why I'm looking for you | 18:37 |
| cjwatson | mrxmike: the output of 'sudo dmidecode' and 'sudo lspci -vvnn' (and 'dmesg', probably) can be useful in isolating machines that need acpi=off and either fixing them or making that the default | 18:38 |
| mdz | bryce: it's starting to smell a bit like evdev | 18:38 |
| mdz | bryce: please have a look at bug 280646 | 18:38 |
| ubottu | Launchpad bug 280646 in hal "ACPI brightness events no longer work on ThinkPad T61" [Medium,Triaged] https://launchpad.net/bugs/280646 | 18:38 |
| bryce | yep looking now | 18:38 |
| bryce | so, you think -evdev is not updating the numlock status correctly? | 18:39 |
| mdz | bryce: whatever is watching num lock and setting the gconf key seems to be failing to unset it | 18:39 |
| mdz | bryce: can you test whether the gconf key gets unset for you when you toggle numlock off? | 18:39 |
| bryce | sure | 18:40 |
| mdz | bryce: just run the gconf command in the bug and toggle it on and off. what happens? | 18:42 |
| bryce | hmm, I get 'true' / 'false' / 'true' | 18:42 |
| bryce | er sorry, reverse that | 18:42 |
| bryce | 'false' / 'true' / 'false' | 18:43 |
| Treenaks | bryce: that's not reverse, that's inverse :) | 18:43 |
| ogra | Treenaks, arguing with a native english speaker ? | 18:43 |
| Treenaks | *hides again* | 18:43 |
| ogra | thats what i call brave :) | 18:43 |
| bryce | mdz, timo has a thinkpad, let me see if he can reproduce | 18:44 |
| cjwatson | that could even be an xkeyboard-config bug ... | 18:45 |
| bryce | ah too bad, he doesn't have access to his laptop | 18:45 |
| mdz | bryce: I can reproduce it here and am happy to help track it down; what can I do? | 18:45 |
| H|V_3ala2 | hey | 18:45 |
| H|V_3ala2 | any1 here? | 18:45 |
| bryce | well, colin's right that it's not certain which component is to blame | 18:46 |
| cjwatson | although I wouldn't expect xkeyboard-config to be responsible for getting the key as far as gconf | 18:46 |
| bryce | cjwatson: yeah, though I'd have said the same of -evdev | 18:46 |
| H|V_3ala2 | any dr watson here? | 18:46 |
| bryce | give me a few minutes to poke through the -evdev source | 18:47 |
| H|V_3ala2 | ACPI: DMI BIOS year==0, assuming ACPI-capable machine,,,,,,,,,,,,,???? | 18:47 |
| cjwatson | bryce: likewise; surely gconf gets it from something hal-ish | 18:47 |
| mdz | bryce: some general guidance on how num lock is handled now would be helpful | 18:48 |
| mdz | where the state is stored | 18:48 |
| mdz | in the input layer, in the X keyboard driver, etc. | 18:48 |
| mdz | cjwatson: fwiw hal itself knows nothing of that key | 18:49 |
| mdz | (s/key/gconf &/) | 18:49 |
| mdz | H|V_3ala2: no one is here | 18:49 |
| bryce | could also be a fault in xserver | 18:49 |
| bryce | mdz, -evdev has special handlers for numlock, and passes it up to the xserver. evdev doesn't do a lot of processing - it's only 3000 lines total. | 18:50 |
| mdz | at times like this, I wish I could do an indexed search of all of the source code in Ubuntu | 18:50 |
| mdz | gnome-settings-daemon knows about it | 18:52 |
| ogra | .oO(wouldnt that be a great sabdfl pet project for launchpad ?) | 18:52 |
| bryce | mdz, yeah these multi-component bugs can be frustrating | 18:53 |
| mdz | bryce: gnome-settings-daemon has a callback which sets this key | 18:53 |
| bryce | mdz, xserver communicates key changes to x11 clients, so I'm wondering if gnome-settings-daemon is that key | 18:53 |
| bryce | er s/key/client/ | 18:53 |
| * bryce hmms | 18:54 | |
| superm1 | if you kill gsd, you can usually intercept a lot more keypresses | 18:54 |
| superm1 | eg via xev | 18:55 |
| mdz | http://paste.ubuntu.com/55736/ is the handler | 18:56 |
| mdz | bryce: what's kbev->state.locked_mods? | 18:57 |
| cjwatson | mdz: I've occasionally used google code search for such purposes | 18:57 |
| bryce | mdz, sounds like a bitmask for lockable modifier keys (num lock, scroll lock, caps lock) | 18:58 |
| bryce | er, bit field | 18:58 |
| * bryce needs more coffee | 18:58 | |
| cjwatson | finds libgnomekbd, sabayon, gnome-applets, control-center and some irrelevant stuff on first page | 18:58 |
| cjwatson | yeah, I believe locked_mods is just the modifiers that are locked | 18:59 |
| cjwatson | (search> for /desktop/gnome/peripherals/keyboard) | 19:00 |
| bryce | libgnomekbd is probably the one to look at | 19:00 |
| mdz | oh god | 19:00 |
| bryce | gnome-control-center probably only comes into play when making configuration changes | 19:00 |
| mdz | numlock_xkb_callback is getting called for *every* *keypress* | 19:00 |
| bryce | ew | 19:00 |
| === robbiew is now known as robbiew_away | ||
| cjwatson | does it just chain through all its key callbacks every time or something? | 19:00 |
| bryce | mdz, is that in gnome-settings-daemon? | 19:01 |
| mdz | bryce: yes | 19:01 |
| mdz | cjwatson: http://paste.ubuntu.com/55738/ | 19:02 |
| CarlFK | I am looking for python PyCon march 09, chicago speakers. Anyone in here have any interested? something about how ubuntu will deal with py3.0 would be great | 19:02 |
| mdz | cjwatson: gdk_window_add_filter(NULL, ...) | 19:02 |
| mdz | null filter == all events | 19:02 |
| bryce | who else has been able to reproduce this bug? Is it truly Thinkpad T61-specific? If so maybe we need to examine how the T61 handles numlock keys differently? | 19:03 |
| mrxmike | mdz: the 32bit version seems to work fine | 19:03 |
| cjwatson | oddly, the pygtk version of add_filter doesn't have that null argument | 19:03 |
| bryce | CarlFK: probably you want to ask on the ubuntu-devel-discuss@ mailing list | 19:03 |
| mdz | bryce: read the bug; there is a person there who was able to reproduce it | 19:03 |
| cjwatson | mdz: NULL as first arg just means all windows, not all events | 19:04 |
| cjwatson | http://library.gnome.org/devel/gdk/stable/gdk-Windows.html#gdk-window-add-filter | 19:04 |
| cjwatson | there may not be a way to install a filter for just one key ... | 19:04 |
| CarlFK | bryce: will do. thanks | 19:04 |
| mdz | cjwatson: you're right, but the effect is the same | 19:05 |
| mdz | cjwatson: the filter func gets called for every event | 19:05 |
| mdz | this is apparently as intended | 19:05 |
| mdz | cjwatson: this makes for a very interesting exercise in trying to use breakpoints | 19:05 |
| bryce | mdz, okay he says he has a thinkpad t61 in another bug. interesting | 19:05 |
| cjwatson | one way xkeyboard-config could come into it would be if the lock modifier isn't properly set when numlock is engaged | 19:06 |
| bryce | I wonder how num_lock is working differently on T61's than on other systems | 19:08 |
| cjwatson | since in general the keysym for a given key may be different when numlock is engaged versus when it isn't, it does have to go through xkeyboard-config | 19:09 |
| ahasenack | bryce: which bug? I'm on a T61 right now | 19:09 |
| bryce | ahasenack: 280646 | 19:09 |
| cjwatson | anyway, I really have to spend some time with my family, they're starting to forget what I look like | 19:09 |
| bryce | ahasenack: see comment 21 for steps to reproduce | 19:09 |
| mdz | pitti: the guest session has turned out to be very useful for debugging | 19:10 |
| mdz | bryce: in a guest session, i confirmed that I see a KeyEvent for the numlock key when numlock state is on, but not when it's off | 19:11 |
| bryce | mdz, via xev? | 19:11 |
| mdz | bryce: yes | 19:11 |
| bryce | ahhhh | 19:12 |
| ahasenack | bryce: hmm, I'm on hardy | 19:12 |
| bryce | ahasenack: you *might* be able to reproduce it by setting your keyboard driver in xorg.conf to "evdev". Alternatively, booting an intrepid live-cd could be sufficient | 19:13 |
| ahasenack | bryce: that gconf --get command always returns "No value set for ..." here | 19:13 |
| ahasenack | bryce: I'll get the live cd | 19:13 |
| mdz | ahasenack: how curious | 19:13 |
| mathiaz | radix: I've looked at your 1.0.23 branch and it looks good. | 19:13 |
| bryce | ahasenack: ok sounds like you'd need to boot the live-cd | 19:13 |
| mathiaz | radix: I've made some editorial changes to the changelog (adding some LP numbers) | 19:13 |
| ahasenack | bryce: is the beta one enough? | 19:14 |
| bryce | ahasenack: yep | 19:14 |
| ahasenack | oh, I have it already :) | 19:14 |
| mdz | bryce: can you confirm that you see a keypress event both times whet toggling it on/off? | 19:14 |
| * ahasenack burns | 19:15 | |
| mdz | I'm going to do some console debugging, brb | 19:16 |
| mathiaz | radix: there is also a new scriptcontent library that doesn't seem to be used anywhere in the code. | 19:17 |
| mdz | bryce: I can reproduce on the console | 19:18 |
| mdz | 'input-events 1' shows num lock the first time, and not the second | 19:18 |
| bryce | mdz, I do get keypress events when toggling it on and off both | 19:18 |
| ahasenack | bryce: wait, I forgot my brain in my bed | 19:18 |
| jmichel | when building a library with dpkg-builpackage, the resulting deb file doesn't contain the files | 19:19 |
| mdz | I have now officially come full circle back to the kernel (where I started!) | 19:19 |
| jmichel | it seems when the script is installing my library it does so in /debian/tmp | 19:19 |
| ahasenack | bryce: the gconf tool command does work as shown in that command, but I have no issues with backlight on my lcd | 19:20 |
| ahasenack | in that comment, I mean | 19:20 |
| mdz | ahasenack: so you can reproduce the gconf/num_lock breakage, but your brightness hotkeys still work? | 19:20 |
| ahasenack | mdz: right | 19:20 |
| jmichel | but the files in the deb archive are taken from /dedian/mylib and /debian/mylib-dev | 19:20 |
| jmichel | any help would be appreciated | 19:20 |
| ahasenack | mdz: via gconf it's always true afterwards, but the backlight continues to be controlled via its keys as usual | 19:20 |
| mdz | ahasenack: please attach the output of "sudo dmidecode" and "dmesg" to the bug | 19:20 |
| bryce | ahasenack: the brightness level thingee is a regression in intrepid | 19:21 |
| ahasenack | mdz: right, I'm still on hardy, just burning the intrepid live cd | 19:21 |
| mdz | ahasenack: you tested the backlight keys on the beta CD, right? | 19:21 |
| ahasenack | mdz: in the next 15min or so | 19:22 |
| bryce | ahasenack: so no surprise you don't have that problem - but presumably if you upgraded right now, you'd have it | 19:22 |
| mdz | ahasenack: oh | 19:22 |
| mdz | so the num lock bug is older, but something else broke the brightness keys when the gconf key is set | 19:22 |
| mdz | that's useful to know | 19:22 |
| bryce | mdz, tried booting an older kernel? | 19:22 |
| ahasenack | and it's maybe not related | 19:23 |
| H|V_3ala2 | ACPI: DMI BIOS year==0, assuming ACPI-capable machine | 19:23 |
| H|V_3ala2 | sos | 19:23 |
| H|V_3ala2 | sos | 19:23 |
| mdz | H|V_3ala2: this is not a support channel, please go to #ubuntu | 19:24 |
| mdz | bryce: I did, but only to verify that the brightness keys didn't work | 19:24 |
| mdz | bryce: I'll check the num lock issue on 2.6.24 | 19:24 |
| mdz | brb | 19:24 |
| radix | mathiaz: hi, sorry, was afk | 19:28 |
| radix | mathiaz: actually, the scriptcontent library is used by the server... the server uses the client code as a library | 19:28 |
| radix | mathiaz: btw, did you see my most recent change? you may have missed it, since I just added it recently. it makes --purge clean up a bunch of stuff | 19:29 |
| mathiaz | radix: hm - ok. But it's not used in the client at all. | 19:29 |
| radix | mathiaz: right, it's not used in the client application yet | 19:30 |
| radix | but it will be | 19:30 |
| mathiaz | radix: ok. | 19:30 |
| mathiaz | radix: I'm reviewing lp:~radix/landscape-client/intrepid-1.0.23/ | 19:30 |
| mathiaz | radix: revno 93 | 19:31 |
| radix | yep, that's the one | 19:31 |
| radix | ah | 19:31 |
| radix | mathiaz: it's at 95 now | 19:31 |
| radix | 94 and 95 are the --purge fixes | 19:31 |
| radix | (for bug #121182) | 19:31 |
| ubottu | Launchpad bug 121182 in landscape-client "Client should remove /var/lib/landscape if --purge is used" [Undecided,In progress] https://launchpad.net/bugs/121182 | 19:31 |
| lukehasnoname | BenC: Know a workaround for bug #273833 ? I can't boot because of it | 19:32 |
| ubottu | Launchpad bug 273833 in v86d "v86d missing from initramfs" [High,In progress] https://launchpad.net/bugs/273833 | 19:32 |
| mathiaz | radix: ok - I'll update the branch then. | 19:32 |
| ogra | lukehasnoname, you should be able to boot if you drop splash from the grub commandline | 19:32 |
| ogra | it will only affect usplash | 19:32 |
| lukehasnoname | ogra: How would i do that, in a nutshell? I want to know for sure what to do, since if I run into something I don't know I'll have to boot back to Vista to get back here. | 19:34 |
| mdz | bryce: do you see events in lshal -m when you use your brightness hotkeys? | 19:35 |
| mdz | ahasenack: do you? | 19:35 |
| ogra | hit esc at if "GRUB" appears on the top left of your screen, go to the kernel you want to boot, hit "e" edit the line, hit b to boot | 19:35 |
| lukehasnoname | mk | 19:36 |
| bryce | mdz, nope, nothing prints out from lshal -m when I use the brightness keys | 19:36 |
| lukehasnoname | I hope I'll be on intrepid next time I talk to you | 19:36 |
| ahasenack | mdz: you want me to try in hardy or would you prefer to wait a bit for me to boot into intrepid beta live cd? | 19:38 |
| ahasenack | bryce: are you on a t61 too? | 19:39 |
| bryce | ahasenack: no I don't have a t61 | 19:40 |
| mdz | bryce: interesting, gpm_button_filter_x_events in gnome-power-manager doesn't even get called when that gconf key is set, regardless of the keyboard state | 19:41 |
| mdz | ahasenack: both please | 19:41 |
| mdz | bryce: can you confirm that on your laptop? | 19:41 |
| ahasenack | mdz: on hardy, where it's currently working: http://pastebin.ubuntu.com/55747/ | 19:41 |
| mdz | ahasenack: output of "sudo lsinput" please? | 19:42 |
| ahasenack | mdz: which package has it? | 19:42 |
| mdz | ahasenack: input-utils | 19:42 |
| bryce | mdz, sure; is there an easy way to check that or did you just hack the code directly? | 19:44 |
| jmichel | Anyone know where I should go for some help using dpkg-buildpackage? maybe another IRC channel ? | 19:44 |
| ahasenack | mdz: http://pastebin.ubuntu.com/55748/ (still on hardy) | 19:44 |
| mdz | bryce: I used gdb | 19:44 |
| ogra | jmichel, #ubuntu-motu probably | 19:45 |
| bryce | mdz, btw I've browsed through xkeyboard-config but nothing jumps out as worth investigating. the handling of keyboard stuff for evdev has changed of course, but there's little that's thinkpad-specific or num-lock specific that looks suspicious | 19:45 |
| jmichel | ogra: thx | 19:45 |
| mdz | ahasenack,bryce: I don't see anything in lshal -m even when it is working for me (ie. numlock_on=false) | 19:45 |
| ahasenack | mdz: numlock is not on here, but gconf still thinks it is | 19:46 |
| mdz | bryce: any guesses why the numlock_on key in gconf seems to affect whether the GDK filter gets called? | 19:52 |
| mdz | bryce: surely gdk doesn't check that gconf key | 19:52 |
| mdz | perhaps something else is listening for changes to that key | 19:52 |
| cjwatson | I don't suppose that numlock_on being set means that the keyboard firmware filters out the key ...? | 19:52 |
| cjwatson | surely not though, you said it worked in hardy | 19:53 |
| bryce | mdz, well it sort of sounds like something is incorrectly applying the locked modifier keys when checking those hotkeys | 19:53 |
| cjwatson | but it rather sounds like it's not making it to gdk | 19:53 |
| === robbiew_away is now known as robbiew | ||
| mdz | cjwatson: google code search is nice, thanks | 19:53 |
| bryce | mdz, in which case I'd wonder if capslock or scrolllock would produce similar misbehavior? | 19:53 |
| cjwatson | bryce: I suggest that we need a hacked evdev with extra printfs | 19:53 |
| cjwatson | it would be very interesting to know whether it's reaching evdev at all, and if so what it looks like on the way in and out | 19:54 |
| mdz | bryce: works fine with caps lock on | 19:54 |
| cjwatson | printf debugging is usually a good first line of attack once you have a starting hypothesis :) | 19:54 |
| mdz | ahasenack: I would appreciate if you could file a separate bug report about the num lock event issue ("ubuntu-bug linux" on the intrepid live CD) while we continue to chase the brightness key part of the problem | 19:56 |
| ahasenack | mdz: ok | 19:56 |
| ahasenack | mdz: I'm just about to reboot into intrepid, just finishing something else up | 19:57 |
| bryce | mdz interesting, yes I can reproduce what you mentioned about gpm_button_filter_x_events not getting called when numlock is on. | 19:59 |
| radix | mathiaz: anything else we should discuss about the package? | 19:59 |
| mdz | bryce: by "numlock" do you mean the keyboard state, or the numlock_on gconf key? | 20:00 |
| NCommander | jdong & ScottK: can one of you ack a backport? | 20:00 |
| mathiaz | radix: not that I can think of for now | 20:00 |
| bryce | mdz, keyboard state | 20:00 |
| radix | mathiaz: should I be doing anything else? | 20:00 |
| mdz | bryce: ok, interesting | 20:00 |
| bryce | cjwatson: ok I can hack something up for testing, let me get some food first | 20:00 |
| mdz | bryce: but your brightness keys still work, presumably because you're getting an event via hal? | 20:00 |
| mdz | I wonder why I don't get a hal event | 20:01 |
| mathiaz | radix: not really. | 20:01 |
| radix | mathiaz: ok, thank you very much! I appreciate your patience :) | 20:01 |
| mathiaz | radix: on a related note, is there a way the tests could be enabled in the build process? | 20:01 |
| mathiaz | radix: but this is not a showstopper for intrepid | 20:02 |
| radix | mathiaz: not in the very short term, unfortunately - the problem is the dependency on a session dbus running | 20:02 |
| radix | mathiaz: it's something I definitely want to do, though | 20:02 |
| radix | mathiaz: if you want to run the tests yourself, you can use "trial -r glib2 landscape" while in the root of the source tree, assuming you have a dbus session bus running | 20:02 |
| radix | I need to figure out a way to start and stop a bus while the tests are running automatically | 20:03 |
| mathiaz | radix: ok - I may try that. | 20:03 |
| radix | and get the tests to connect to that particular bus address | 20:03 |
| mathiaz | radix: anyway it's not a showstopper for intrepid | 20:03 |
| radix | ok | 20:03 |
| mdz | bryce: I could possibly understand it not being called when the keyboard state is set, but I find it very puzzling that toggling the gconf key changes the behaviour | 20:03 |
| mdz | bryce: I think I agree with cjwatson that an instrumented evdev would be enlightening | 20:07 |
| ScottK | NCommander: Can you fix openexr on hppa? | 20:09 |
| NCommander | On the todo list | 20:09 |
| * NCommander is working on one crisis at a time :-) | 20:09 | |
| NCommander | ScottK, sorry for running off last night, working fire, and a massive one at that | 20:09 |
| mdz | aha! it's gnome-settings-daemon meddling | 20:10 |
| ScottK | NCommander: Bug? | 20:10 |
| mdz | if I STOP gnome-settings-daemon and toggle the gconf key, the brightness keys continue working | 20:10 |
| NCommander | ScottK, huh? | 20:10 |
| ScottK | NCommander: What's the bug for the backport you need ack'ed? | 20:11 |
| NCommander | There are a LOT of bugs, over 25% that are confirmed/in progress, so I would really like to see some of these move | 20:11 |
| NCommander | its the talloc backport, its a blocker on another one | 20:11 |
| NCommander | ScottK, https://bugs.edge.launchpad.net/hardy-backports/+bug/269161 | 20:12 |
| ubottu | Launchpad bug 269161 in hardy-backports "Please backport talloc 1.2.0~git20080616-1 from hardy to intrepid" [Low,Confirmed] | 20:12 |
| ScottK | OK. I'll have a look at that one. I don't have time for a general sweep through them now. | 20:12 |
| * NCommander nods | 20:12 | |
| ScottK | NCommander: I feel a little nervous about a samba backport. Have you tested that? | 20:13 |
| NCommander | I did awhile ago. The package probably been updated since then, so it needs to be retested | 20:13 |
| mdz | bryce: gnome-settings-daemon propagates the gconf numlock state to XKB via XkbLockModifiers | 20:13 |
| cody-somerville | NCommander, stop trying to break stuff :P | 20:13 |
| NCommander | cody-somerville, I did that all last night | 20:14 |
| ScottK | NCommander: You can make one bug for a backport of multiple packages. Please update this one to cover both and once it's tested, I'll approve them together. | 20:14 |
| NCommander | ok | 20:14 |
| andreas | mdz: so, after booting into intrepid-beta live, I got brightness setting working, but no OSD | 20:14 |
| andreas | mdz: also, lshal -m doesn't report any event while I change the brightness settings | 20:15 |
| mdz | andreas: does changing the numlock setting have any effect? | 20:15 |
| andreas | mdz: no. Still no event on lshal -m, still no osd, and brightness setting continues working | 20:15 |
| andreas | mdz:the osd works for other stuff, though, like volume setting via the volume hotkeys | 20:16 |
| mdz | andreas: this is crazy | 20:16 |
| mdz | it's like there are six different ways that this COULD work, and some of them are always broken | 20:17 |
| mdz | andreas: which keyboard layout do you use? | 20:17 |
| mdz | slangasek: do your brightness keys work? | 20:17 |
| andreas | mdz: on hardy I use brazilian abnt2 + thinkpad, but on in trepid now it's standard us with no dead keys | 20:18 |
| mdz | andreas: try changing it on intrepid to match your hardy config? | 20:18 |
| bryce | mdz, right even with g-p-m not breaking, the brightness changes were taking effect | 20:20 |
| bryce | mdz, interestingly I can see it skipping through multiple steps in each keypress... which is probably wrong... but unrelated to this problem | 20:21 |
| mdz | bryce: your keys may work in hardware | 20:21 |
| mdz | bryce: lshal | grep laptop_panel.brightness_in_hardware | 20:22 |
| mdz | bryce: in which case g-p-m is just getting notification of the change and displaying the OSD | 20:22 |
| mdz | (the part which is broken for andreas) | 20:22 |
| bryce | $ lshal | grep laptop_panel.brightness_in_hardware | 20:24 |
| bryce | laptop_panel.brightness_in_hardware = false (bool) | 20:24 |
| bryce | laptop_panel.brightness_in_hardware = false (bool) | 20:24 |
| bryce | laptop_panel.brightness_in_hardware = true (bool) | 20:24 |
| andreas | mdz: so, the exact layout is not available under system->preferences->keyboard (it's missing the Thinkpad variant) | 20:24 |
| mdz | bryce: I'm guessing your laptop doesn't actually have three LCDs... | 20:24 |
| andreas | mdz: other than that, the behaviour is the same | 20:24 |
| bryce | hmm, I can also confirm that with numlock set, the keys work but the OSD doesn't display | 20:24 |
| bryce | mdz, heh | 20:24 |
| bryce | mdz, not today | 20:24 |
| andreas | I get two answers only for that lshal | grep ..., and both are true | 20:25 |
| bryce | mdz, so what's the next step - still want the instrumented -evdev, or is it looking like g-s-d is responsible? | 20:25 |
| mathiaz | radix: when purging landscape-common, why not just rm -rf ${LOG_DIR} ? | 20:25 |
| radix | mathiaz: I wasn't sure if that was bad, I couldn't really find much policy documentation about what to do during purge | 20:26 |
| mdz | bryce: I still want to know what evdev is doing | 20:26 |
| radix | mathiaz: I was under the impression that that command in particular would be bad because $LOG_DIR is actually a directory in the package | 20:26 |
| slangasek | mdz: yes, though they work by indeterminate means; I think they're being handled in hardware against my wishes | 20:27 |
| mathiaz | radix: hm - correct - may be rm -rf ${LOG_DIR}/*? | 20:27 |
| radix | mathiaz: sure, that would work | 20:27 |
| _Zeus_ | mathiaz: is the /* nessecary? | 20:27 |
| radix | I guess it's a matter of being conservative.. if someone puts a random file in /var/log, then it won't be deleted the way I have it | 20:27 |
| bryce | looks like the three devices with the brightness_in_hardware are /org/freedesktop/Hal/devices/computer_backlight_0, /org/freedesktop/Hal/devices/computer_backlight, and /org/freedesktop/Hal/devices/dell_lcd_panel | 20:27 |
| mathiaz | radix: right - OTOH that means if a new log file is added, one has to remember that the postrm script needs to be updated. | 20:28 |
| mdz | bryce: right, so yours are being handled in hardware, so you've no problem changing the brightness, but you can reproduce the problem in that the OSD doesn't display (for the same reasons) | 20:28 |
| radix | mathiaz: yeah, true. but then, what would landscape-client do? it can't remove *, because it would remove sysinfo.log. | 20:29 |
| bryce | alright, one instrumented -evdev coming up... | 20:30 |
| mdz | bryce: that should give you enough to chase this on your own | 20:30 |
| mdz | I'm going to have to quit soon, my wrists are shot | 20:30 |
| mathiaz | radix: hm - good point | 20:30 |
| radix | mathiaz: maybe we could separate them out into different log directories, that would definitely make it easier from this perspective | 20:31 |
| radix | but that would require some more source changes | 20:31 |
| mathiaz | radix: right - it may not be worth the trouble. | 20:31 |
| cjwatson | _Zeus_: the reason for the /* is that the directory itself is shipped in the package | 20:34 |
| cjwatson | _Zeus_: as was said just a couple of lines above :) | 20:34 |
| * andreas goes back to hardy | 20:35 | |
| _Zeus_ | cjwatson: oh, oh. didn't see that | 20:36 |
| kirkland | cjwatson: it's been a couple of hours... is there somewhere I can check the status of those server iso re-spins? | 20:37 |
| kirkland | cjwatson: i don't see anything here: http://cdimage.ubuntu.com/ubuntu-server/ | 20:37 |
| kirkland | cjwatson: anything meaning a second spin sync'd out yet | 20:37 |
| cjwatson | that's 'cos I didn't start them. give me a minute ... | 20:37 |
| kirkland | cjwatson: :-) kthx | 20:37 |
| cjwatson | the couple of hours was until it was worthwhile starting them | 20:37 |
| === nxvl_ is now known as nxvl | ||
| === bddebian2 is now known as bddebian | ||
| === Guest52963 is now known as jelmer | ||
| === jelmer is now known as Guest30665 | ||
| james_w | I'm back at looking at the pm-utils/uswsusp issue | 21:11 |
| james_w | never mind, I need to look at the new upstream in more depth to work out what will happen next cycle before asking that question | 21:12 |
| === Guest30665 is now known as Guest52963 | ||
| sebner | james_w: btw, I'll check this ssmtp thing tomorrow :) | 21:15 |
| james_w | sebner: thanks. An alternative would be asking the security team whether it even matters for uploads to development releases | 21:16 |
| sebner | james_w: why not? besides looks like a SRU back to Dapper | 21:16 |
| james_w | sebner: dapper? I was expecting just hardy. | 21:18 |
| sebner | james_w: well 2.62 and 2.61 is affected and dapper also has 2.61 IIRC | 21:19 |
| sebner | james_w: yep, unfortunately. so we just can ignore edgy and feisty | 21:19 |
| mdz | bryce: any luck? | 21:20 |
| james_w | sebner: sure, have you done security updates before? | 21:20 |
| sebner | james_w: once but my mentor is from the SRU team so I'll talk to him tomorrow | 21:21 |
| bryce | mdz, still instrumenting and reviewing code... I did run across one unfinished piece of code that I'm curious about | 21:21 |
| bryce | mdz, I've also reviewed -evdev changes in git upstream, and there's a couple changes I wonder might have an effect. It may be worthwhile to test the upstream git -evdev | 21:22 |
| === fta_ is now known as fta | ||
| sebner | james_w: if that's ok for you!? | 21:24 |
| james_w | sebner: of course | 21:25 |
| sebner | james_w: fine. and thx for the hint with the correct changelog thing (also I haven't seen that many in this manner though ;)) | 21:26 |
| james_w | no, I think it more for security updates to stable release, but it can't hurt | 21:26 |
| sebner | james_w: ah ok. but developement or not. it's a bug/security issue and it should be fixed ASAP | 21:27 |
| james_w | yeah | 21:27 |
| slangasek | pitti: hmm, how about if I re-upload samba with -v so that we can supersede 4.6 without losing the tracking :) | 21:30 |
| mdz | bryce: did you try it? | 21:30 |
| bryce | mdz, hang on | 21:31 |
| mdz | bryce: I just did. no change. | 21:32 |
| bryce | :-P | 21:32 |
| bryce | ok, thanks | 21:32 |
| bryce | I'll finish building debs of it anyway | 21:32 |
| slangasek | pitti: (done, please consider accepting ubuntu4.7 once it reaches the queue) | 21:34 |
| mdz | bryce: I just built it from git and copied the .so | 21:34 |
| mdz | bryce: interestingly, that crashed the X server | 21:34 |
| mdz | bryce: I have a .crash from that if you want it | 21:35 |
| === Guest52963 is now known as jelmer | ||
| bryce | http://bryceharrington.org/ubuntu/EvdevBug280646/ | 21:38 |
| bryce | that's the instrumented deb. the git snapshot will take a couple more minutes | 21:39 |
| mdz | bryce: can you upload the source? I'm on amd64 | 21:41 |
| cjwatson | kirkland: btw, that server CD build finished a while ago, sorry I forgot to mention | 21:42 |
| cjwatson | kirkland: you may have noticed already ;-) | 21:42 |
| kirkland | cjwatson: already pulling it ;-) | 21:42 |
| kirkland | cjwatson: watch -n 60 wget http://cdimage.ubuntu.com/ubuntu-server/daily/current/MD5SUMS -O- ;-) | 21:44 |
| cjwatson | hah | 21:44 |
| mdz | kirkland: --differences --cumulative | 21:45 |
| bryce | mdz, source and amd64 debs -> http://bryceharrington.org/ubuntu/EvdevBug280646/ | 21:45 |
| mdz | bryce: brb | 21:46 |
| kirkland | mdz: right ;-) | 21:46 |
| mdz | bryce: | 21:48 |
| mdz | (II) [bwh] EvdevReadInput() | 21:48 |
| mdz | (II) [bwh] Posting keyboard event | 21:48 |
| mdz | (II) [bwh] PostKbdEvent: value=1 | 21:48 |
| mdz | (II) [bwh] Posting keyboard event code=233, value=1... | 21:48 |
| mdz | (II) [bwh] Posting keyboard event | 21:48 |
| mdz | (II) [bwh] PostKbdEvent: value=0 | 21:48 |
| mdz | (II) [bwh] Posting keyboard event code=233, value=0... | 21:48 |
| mdz | bryce: I've emailed you the full log | 21:48 |
| bryce | ok thanks | 21:48 |
| crazychenz | hello | 21:48 |
| bryce | is the above from hitting numlock, or from toggling the brightness keys? (or both?) | 21:48 |
| mdz | bryce: brightness | 21:49 |
| crazychenz | i was curious if anyone could explain or point to what the configparams file does when building glibc 2.7 | 21:49 |
| bryce | mdz, do you get the same output regardless of numlock state? | 21:50 |
| mdz | bryce: looks exactly the same | 21:50 |
| bryce | wow interesting | 21:51 |
| mdz | bryce: by the way, would you mind deleting the bit of that log with my password in it? :-P | 21:51 |
| bryce | mdz, yikes, sure | 21:51 |
| bryce | mdz, btw, do you have a high limit on your credit card? | 21:51 |
| mdz | bryce: http://paste.ubuntu.com/55780/ | 21:53 |
| mdz | that's brightness up, brightness down, num lock, brightness up, brightness down, num lock | 21:53 |
| jdstrand | cjwatson: hi! I noticed your comment about patch systems in an openssh bug. what is the advantage of not using a patch system in this particular case? (if this has been beat to death, feel free to tell me :) | 21:53 |
| mdz | bryce: code=151 appears to be the Fn key | 21:53 |
| mdz | 233 is brightness up, 232 is brightness down | 21:53 |
| cjwatson | jdstrand: I avoid patch systems in all my packages where possible | 21:54 |
| cjwatson | jdstrand: when dpkg-source -x natively extracts with the patches pre-applied, I'll change my position | 21:55 |
| cjwatson | jdstrand: until then I object to the confusion caused | 21:55 |
| cjwatson | yes, I realise my position is at variance with many other people here | 21:55 |
| mdz | bryce: what's 'value='? | 21:56 |
| mdz | bryce: is that press/release? | 21:56 |
| jdstrand | cjwatson: interesting. you just want to quickly get at the actual working code | 21:56 |
| mdz | bryce: if so, what's value=2? | 21:56 |
| cjwatson | jdstrand: no, I think users deserve to be able to get at the actual working code without having to guess how to apply patches | 21:56 |
| cjwatson | jdstrand: I've wasted too much of my life guessing debian/rules invocations to get patch systems to give me the code that's actually compiled | 21:57 |
| cjwatson | the very very slow move to standardise on 'debian/rules patch' is helping a bit | 21:57 |
| jdstrand | cjwatson: fair enough. curious if you are aware of 'what-patch' | 21:57 |
| cjwatson | as is the new requirement in Debian policy to describe the patch system in use in a standard place | 21:57 |
| cjwatson | jdstrand: yes, I am | 21:57 |
| cjwatson | however, it only names the patch system, and doesn't tell you how to use it; and it misses out all the weird cases, things like bash | 21:58 |
| jdstrand | cjwatson: I find when doing security updates for patchless systems, I end up doing a lot of manual 'stuff'. do you happen to have any scripts, etc for dealing with patchless systems? | 21:58 |
| cjwatson | how come? patchless systems are the simplest, they're a strict subset of everything else | 21:59 |
| cjwatson | you need fewer scripts, not more | 21:59 |
| jdstrand | cjwatson: I guess I'm thinking more of extraction | 21:59 |
| cjwatson | yes, if you want to break out individual patches, that takes some manual work | 22:00 |
| cjwatson | but that's really only when you're sending things upstream, and I regard the hard work there as an incentive to keep the number of patches down | 22:00 |
| cjwatson | it can also be mitigated by revision control | 22:00 |
| jdstrand | true enough | 22:01 |
| cjwatson | I don't understand why you would need to worry about that for security updates; can you explain? | 22:01 |
| jdstrand | cjwatson: eg, if I am comparing with/pulling from Debian | 22:02 |
| cjwatson | I would have thought you'd largely just want to apply the patch (massaging it into place as necessary) | 22:02 |
| cjwatson | debdiff is a fine comparison tool, and works best on patchless packages because you don't get the diff-of-a-diff effect | 22:02 |
| bryce | mdz, well... this -evdev code isn't very well documented (i.e. no comments)... however it appears to be something relating to the modifier level I'm guessing? | 22:02 |
| jdstrand | cjwatson: sure, and I find myself going to snapshot.debian.net and doing just that | 22:02 |
| bryce | value=2 _seems_ to correspond to a test if ctrl/alt/shift/capslock/scrolllock is pressed | 22:03 |
| bryce | +/numlock | 22:03 |
| cjwatson | jdstrand: that seems a perfectly normal way to work, to me | 22:03 |
| jdstrand | cjwatson: well, I get to play with all the different philosophies, so I was wondering what I was missing with patchless | 22:03 |
| cjwatson | bryce: it's not something like the modifiers as in keymaps(5) is it? | 22:03 |
| cjwatson | jdstrand: simplicity, and that revision control works best when you aren't trying to shoehorn patches into it | 22:04 |
| cjwatson | jdstrand: your revision control can just be a straightforward branch from upstream | 22:04 |
| bryce | cjwatson: again, I'm just piecing together guesses here, but yes sounds like similar | 22:04 |
| * jdstrand nods | 22:04 | |
| bryce | i.e.: | 22:05 |
| bryce | if (value == 2 && | 22:05 |
| bryce | (ev->code == KEY_LEFTCTRL || ev->code == KEY_RIGHTCTRL || | 22:05 |
| bryce | ev->code == KEY_LEFTSHIFT || ev->code == KEY_RIGHTSHIFT || | 22:05 |
| bryce | ev->code == KEY_LEFTALT || ev->code == KEY_RIGHTALT || | 22:05 |
| bryce | ev->code == KEY_LEFTMETA || ev->code == KEY_RIGHTMETA || | 22:05 |
| bryce | ev->code == KEY_CAPSLOCK || ev->code == KEY_NUMLOCK || | 22:05 |
| bryce | ev->code == KEY_SCROLLLOCK)) /* XXX windows keys? */ | 22:05 |
| jdstrand | cjwatson: I won't take up any more of your time. thanks! :) | 22:05 |
| cjwatson | jdstrand: ideally, patches would be something exported from the revision control system (e.g. bzr looms); all other things being equal they are strictly less convenient than just modifying the code directly (as you would in any normal project, or e.g. if you were the upstream developer); the reason people like them is essentially because they provide a crude form of revision control | 22:05 |
| cjwatson | but nowadays we ought to be able to put together more sophisticated ways of doing that kind of thing | 22:06 |
| bryce | not sure what value=0/1 is; keyboard up/down events ?? | 22:06 |
| cjwatson | jdstrand: I'm waiting for a cscvs bug fix before I can get openssh imported into bzr, at which point I'll probably start experimenting with looms for it | 22:06 |
| jdstrand | cjwatson: I'd agree with that, once Ubuntu is in bzr, this probably become a non-issue | 22:06 |
| cjwatson | (at the moment it's in cvs, ugh) | 22:06 |
| cjwatson | I don't want to convert it to bzr until I can make it be a proper branch from upstream though | 22:07 |
| jdstrand | sure-- that would be a serious pain :) | 22:07 |
| munckfish | guys are we going to be import upstream git repositories into bzr too? | 22:08 |
| munckfish | E.g. kernel? | 22:08 |
| bryce | (or xorg) | 22:08 |
| cjwatson | 'value' is the value the event carries. Either a relative change for | 22:09 |
| cjwatson | EV_REL, absolute new value for EV_ABS (joysticks ...), or 0 for EV_KEY for | 22:09 |
| cjwatson | release, 1 for keypress and 2 for autorepeat. | 22:09 |
| cjwatson | linux/Documentation/input/input.txt | 22:09 |
| bryce | cjwatson: aha thanks | 22:09 |
| bryce | autorepeat? | 22:09 |
| cjwatson | munckfish: git imports are a high-priority feature goal for the Launchpad code team | 22:09 |
| cjwatson | munckfish: (so yes, though not just yet since it's not ready) | 22:09 |
| bryce | ah okay I understand, autorepeat makes sense here | 22:10 |
| munckfish | cjwatson: blimey so the kernel team are going to swap to using bzr too? Or will it just be a front end on Launchpad? | 22:10 |
| cjwatson | munckfish: that remains to be seen | 22:10 |
| munckfish | cjwatson: ;) | 22:10 |
| bryce | ok, so 0 = keyup, 1 = keydown, 2 = keyhold | 22:10 |
| cjwatson | munckfish: they have a good deal of workflow built up around git and I don't imagine they'll be able to switch overnight | 22:10 |
| munckfish | yeah I thought so | 22:10 |
| bryce | cjwatson: I'm willing to guinea pig xorg | 22:11 |
| bryce | cjwatson: we only manage 3-4 packages in git presently | 22:11 |
| bryce | (and personally I find it a bit frustrating, so look forward to doing it with bzr) | 22:12 |
| cjwatson | Debian xorg is all in git, isn't it? | 22:12 |
| bryce | yes | 22:12 |
| cjwatson | it'd probably be good to be able to merge from them easily before switching | 22:12 |
| cjwatson | although working in bzr would be no worse than working outside revision control, in cases where you do that | 22:13 |
| cjwatson | it's also possible to do rolling imports from git to bzr today with git fast-export | bzr fast-import -, but you may have to be prepared to throw away the branch in the future | 22:13 |
| cjwatson | (that's what I'm doing with debian-policy) | 22:13 |
| bryce | ok, going to reboot with the instrumented evdev and see if I get the same results as mdz. brb | 22:15 |
| mdz | bryce: I have some new information | 22:19 |
| mdz | bryce: if I start a guest session, run xkbwatch (shows nothing), then press num lock (some things light up), then press num lock again, then some of the indicators in xkbwatch are still lit | 22:20 |
| mdz | if only I knew what any of them meant | 22:20 |
| mdz | bryce: can you recommend an alternative to xkbwatch which uses names rather than blinking lights? | 22:20 |
| bryce | mdz, no but I can investigate that for you | 22:21 |
| bryce | meanwhile, one difference I notice between your log and mine, is when I do brightness up, I see 8 of the code=233 lines | 22:22 |
| bryce | whereas you see 2 | 22:22 |
| bryce | (II) [bwh] Posting keyboard event code=233, value=1... | 22:24 |
| bryce | (II) [bwh] Posting keyboard event code=233, value=1... | 22:24 |
| bryce | (II) [bwh] Posting keyboard event code=233, value=0... | 22:24 |
| bryce | (II) [bwh] Posting keyboard event code=233, value=1... | 22:24 |
| bryce | (II) [bwh] Posting keyboard event code=233, value=0... | 22:24 |
| bryce | (II) [bwh] Posting keyboard event code=233, value=0... | 22:24 |
| bryce | (II) [bwh] Posting keyboard event code=233, value=1... | 22:24 |
| bryce | (II) [bwh] Posting keyboard event code=233, value=0... | 22:24 |
| mdz | cjwatson: do you know how to dump the current X modifier state? | 22:26 |
| bryce | mdz, xkbwatch.c is a tiny program. how about I just hack it into printing the values | 22:27 |
| lifeless | does anyone know of a trivial-to-use isolate-this-shell-script-please command ? | 22:27 |
| mdz | bryce: if you like | 22:27 |
| mdz | lifeless: for what value of 'isolate'? | 22:27 |
| lifeless | something that will just put a mutex around the script basically, resets on reboots, but otherwise only allows one instance to run | 22:27 |
| bryce | mdz, well if you'd find it useful? | 22:27 |
| lifeless | mdz: ^ | 22:28 |
| mdz | bryce: I'm starting to become convinced that it is simply the num lock modifier which gets stuck on | 22:28 |
| mdz | bryce: but I'm left to wonder why the X server has a num lock modifier at all | 22:28 |
| mdz | given that it seems to be handled at a lower level than X | 22:28 |
| mdz | and X doesn't actually notice whether it's on or off in the hardware | 22:28 |
| munckfish | hi calc did you get a chance to test out that build fix for the !x86 ftbfs? | 22:32 |
| === ompaul_ is now known as ompaul | ||
| bryce | mdz, ok well here's a patch for xkbwatch - http://bryceharrington.org/ubuntu/EvdevBug280646/x11-xkb-utils-xkbwatch-dbg.patch | 22:43 |
| bryce | it prints numbers rather than names tho | 22:43 |
| ScottK | superm1: Thanks for you kdebluetooth fixes. I guess based on your mail I don't need to tell you we aren't there yet. | 23:17 |
| ScottK | superm1: Do you know if there's a bug already on the solid issues? | 23:17 |
| superm1 | ScottK, I'm not sure. I just installed KDE on a test machine and started grepping around until I found where problems were | 23:18 |
| ScottK | superm1: OK. pitti had the one you fixed on the Intrepid RC bug list. I think we need an appropriate one for the remaining problems to replace it. | 23:18 |
| superm1 | ScottK, could you summarize that into another bug then? Probably mark any crasher bugs that are using solid-bluetooth in some way too. | 23:19 |
| ScottK | OK. Let me see what I can do. | 23:19 |
| superm1 | ScottK, i'll try the small diff that I came up that will cover some more of the solid changes after it finishes building, but I know that there are some other bigger API changes, so it will probably be better to wait for the solid bluetooth authors to update the rest | 23:20 |
| superm1 | assuming they'll be doing it in a timely fashion | 23:20 |
| kirkland | cjwatson: excellent, virtio disk is autodetected again in the installer | 23:27 |
| kirkland | cjwatson: i'm chasing down another problem, though. the install succeeds but the installed disk won't boot | 23:27 |
| ScottK | superm1: What's your LP ID? | 23:27 |
| kirkland | cjwatson: i'm looking at the grub install bit | 23:27 |
| superm1 | ScottK, superm1 | 23:28 |
| ScottK | superm1: Bug #280997 pointed at you. | 23:28 |
| ubottu | Launchpad bug 280997 in kdebase-workspace "solid-bluetooth needs update for bluez 4.x" [High,Confirmed] https://launchpad.net/bugs/280997 | 23:28 |
| ScottK | pitti: Please use this bug now to track the KDE Bluetooth RC issue ^^ | 23:28 |
| ScottK | superm1: Gotta run and fix dinner. See you later. Thanks for looking into it. | 23:29 |
| superm1 | okay see ya ScottK | 23:29 |
| ScottK | asac: Did the new Network-Manager get tested with Knetworkmanager before it was uploaded? Bug #280919 | 23:37 |
| ubottu | Launchpad bug 280919 in network-manager "NetworkManager 0.7~~svn20081008t224042-0ubuntu1 breaks Knetworkmanager" [Undecided,Confirmed] https://launchpad.net/bugs/280919 | 23:37 |
| lfaraone | Hey, what is the package in which the ~/Examples files are kept? | 23:38 |
| superm1 | example-content i believe | 23:38 |
| TheMuso | Yes, example-content. | 23:39 |
| lfaraone | superm1: thanks | 23:39 |
| lfaraone | What format would a patch have to be in for a file in example-content? The speex file has crappy quality. | 23:46 |
| lfaraone | ( would a FFE be needed for bug 208561 ? ) | 23:53 |
| ubottu | Launchpad bug 208561 in example-content "Speex Audio file is a non-ideal bit-rate" [Low,Triaged] https://launchpad.net/bugs/208561 | 23:53 |
| crimsun | lfaraone: doubtful, though it's more wishlist | 23:56 |
| lfaraone | crimsun: ah, good. | 23:58 |
| lfaraone | crimsun: what kind of patch is needed? standard debdiff? (the reporter wants to help fix, I've offered to mentor) | 23:58 |
| wgrant | What is the size delta? | 23:59 |
| wgrant | A debdiff won't work -- it's binary. | 23:59 |
| crimsun | you'd need to upload an entirely new source package with it re-encoded from the source | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!