[00:24] <rackerhacker> jjohansen: i'm back with a linux-ec2 question if you're around ;)
[00:30] <jjohansen> sure
[00:30] <jjohansen> though I have a couple bugs against it, that I still have to look into
[00:31] <jjohansen> rackerhacker: ^
[00:36] <rackerhacker> ah, okay, that may be unrelated
[00:37] <rackerhacker> i git a git clone of the latest, picked up the ec2 branch, but the fdr doesn't generate debian.ec2/build any longer
[00:37] <rackerhacker> caught me a little off guard
[00:38] <jjohansen> rackerhacker: do an fdr clean first
[00:38] <rackerhacker> i did that... did a clean followed by a prepare-ec2
[00:38] <jjohansen> how about binary-ec2
[00:38] <jjohansen> or just binary
[00:38] <rackerhacker> hmm, i'll give that a try
[00:39] <rackerhacker> i think i owe you a case of beer for how much you've helped already ;)
[00:39] <jjohansen> warning on this kernel it seem there is an issue with it not booting Bug #527208
[00:39] <ubot3> Malone bug 527208 in linux-ec2 "ec2 instance fails boot, no console output on  c1.xlarge" [Medium,Confirmed] https://launchpad.net/bugs/527208
[00:39] <jjohansen> on c1.xlarge
[00:40] <rackerhacker> i'll go take a look at that one
[00:40] <jjohansen> hopefully we can get it cleaned up soon, just haven't gotten to it yet
[00:40] <rackerhacker> so far, it's been a rock solid kernel
[00:40] <rackerhacker> but i'm not using it at ec2 ;)
[00:41] <jjohansen> rackerhacker: glad to here its stable for you
[00:41] <jjohansen> I assume your using it as dom0
[00:42] <rackerhacker> domU actually
[00:42] <jjohansen> ah, just not on ec2
[00:42] <rackerhacker> i haven't tested it as a dom0 to be honest
[00:42] <jjohansen> me neither :)
[00:42] <rackerhacker> yeah, not on ec2... i work for a competitor
[00:42] <rackerhacker> you haven't tried it as a dom0?
[00:43] <jjohansen> nope, I have been to busy with other things
[00:44] <rackerhacker> i could imagine... that lucid release is coming up quickly
[00:44] <jjohansen> my focuses has been making sure it works for EC2, and then get back to other stuff
[00:44] <jjohansen> yep, frighteningly fast
[00:44] <rackerhacker> well i can certainly toss it around as a dom0 if that'd help you in the future
[00:44] <rackerhacker> 2.6.18 is getting old :/
[00:45] <jjohansen> rackerhacker: be my guest but I don't know that its something that will ever be supported again
[00:46] <rackerhacker> alrighty
[00:48] <rackerhacker> looks like fdr binary-ec2 just starts building it immediately
[00:50] <rackerhacker> these are the steps i had noted from you before -> http://pastie.org/private/k0uazxqyxrrj0ygsp6qcq
[00:53] <jjohansen> rackerhacker: yeah, the prepare isn't necessary if you are just looking to build
[00:53] <jjohansen> fdr clean followed by fdr binary-ec2 will do
[00:54] <rackerhacker> ah, i thought prepare was necessary to set up debian.ec2/build
[00:54] <jjohansen> build will do it if it doesn't find the prepare stamp
[00:54] <jjohansen> so it gets done, you just don't manually have to do it
[00:54] <jjohansen> I do it to update the version string etc
[00:55] <rackerhacker> ah, so dump my .config into the base directory and use binary-ec2?
[00:55] <jjohansen> nope
[00:55] <rackerhacker> sorry, i'm still new to the ubuntu way of doing this :/
[00:55] <jjohansen> if you are updating the config, you can either do
[00:55] <jjohansen> fdr editconfigs
[00:55] <jjohansen> and that will refactor configs etc
[00:55] <jjohansen> or you do a prepare
[00:56] <jjohansen> dump your new configs into build
[00:56] <jjohansen> and touch the stamps
[00:56] <jjohansen> you need to make sure to touch the stamps files in the build dir, other wise what you dump in there will get overwritten
[00:57] <rackerhacker> ah, i think the prepare route is the way i need to go
[00:57] <jjohansen> think standard make time based deps
[00:57] <jjohansen> yeah, if you are updating the configs and don't want to maintain a patch in git
[00:57] <jjohansen> the other option is doing fdr editconfigs
[00:58] <jjohansen> commit your config changes to your tree
[00:58] <jjohansen> and then when you fetch our tree rebase, so that your changes are applied over top
[00:58] <jjohansen> of course config changes will probably break you patch
[00:59] <rackerhacker> i didn't think of that... good idea
[01:00] <jjohansen> if you do that, you shouldn't need the separate prepare step
[01:03] <rackerhacker> awesome
[01:07] <jjohansen> rackerhacker: question, would us moving to a pv-ops based kernel for EC2 affect you?
[01:07] <rackerhacker> jjohansen: are you talking about dropping the ec2 patchset and making it more like the upstream?
[01:08] <jjohansen> rackerhacker: yep
[01:08]  * rackerhacker gasps
[01:08] <jjohansen> not saying it is going to happen, but it could
[01:08] <rackerhacker> hah, we're still using /dev/sda and tty1, so that'd be painful
[01:08] <jjohansen> we tried it with karmic and ran into some pretty serious problems we couldn't resolve
[01:09] <rackerhacker> i did a ton of testing with 2.6.31.6 w/pv_ops and had a lot of time skew issues
[01:09] <jjohansen> hrmm, I wasn't aware of time skew issues
[01:09] <rackerhacker> as much as 8 minutes after 3-4 days on that kernel
[01:10] <rackerhacker> we had to pull it due to the complaints and search for an alternative
[01:10] <jjohansen> hrmm, that is something I will have to try
[01:10] <rackerhacker> one of the canonical folks works for us now and he made the linux-ec2 suggestion
[01:11] <jjohansen> ah
[01:11] <jjohansen> well banging on pv-ops again and seeing if I can't make it work is on my todo
[01:12] <jjohansen> knowing issues, is a very good thing
[01:12] <rackerhacker> i think the most painful part for me is getting our customers off /dev/sda and tty1
[01:12] <rackerhacker> the xvda -> sda patch is simple, and it works fine
[01:12] <rackerhacker> but getting hvc0 out and using tty1 instead is rough
[01:13] <jjohansen> rackerhacker: I think atm we would be patching our kernels to use those as well
[01:13] <jjohansen> rackerhacker: if I get a kernel that looks like it is working I will point you at it
[01:14] <rackerhacker> jjohansen: i'll be happy to test for you
[01:14] <jjohansen> thanks
[01:14] <rackerhacker> and i might be able to get my company to get behind it with whatever's needed
[01:15] <rackerhacker> i need to get pvgrub rolling ;)
[09:28] <poolie> hi, i upgraded /backup on my lucid desktop to ext4 the other day
[09:28] <poolie> now it's getting io errors along the lines of
[09:28] <poolie> Feb 25 17:45:37 grace kernel: [37152.894557] EXT4-fs error (device dm-4): make_indexed_dir: invalid rec_len for '..' in inode 2933963
[09:28] <poolie> is anyone interested in debugging this, or should i just fsck and try to recover?
[09:29] <amitk> poolie: it might be worth it just to post your dmesg to a bug and post a link here
[09:30] <poolie> ok, will do
[09:38] <poolie> csurbhi/amitk, i filed https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/527644
[09:38] <ubot3> Malone bug 527644 in linux "lucid ext4  make_indexed_dir: invalid rec_len for '..' in inode" [Undecided,New] 
[09:38] <poolie> let me know if you want any more info or if you have any suggestions
[09:38] <apw> apw
[09:38] <apw> apw_
[09:39] <apw> poolie, i assume you fskc'd it as part of the upgrade to ext4 ?
[09:39] <poolie> i did
[09:39] <poolie> only the one time recommended by the upgrade doc
[09:40] <poolie> during which it updates the checksums
[09:40] <apw> reasonable
[09:40] <poolie> i haven't changed those files since then though
[09:40] <poolie> they're unchanged since 20070706
[09:41] <apw> its somewhat supprising that the encoding of . and .. in a directory would be broke
[09:41] <poolie> i'm a bit concerned because i upgraded /home at the same time, perhaps foolishly
[09:42] <apw_> you have me concerned too, as i was about to do my rootfs 
[09:43] <lifeless> poolie: did you run the example fsck flags?
[09:43] <poolie> -D etc, yes, of course
[09:43] <lifeless> poolie: the main thing it needs to rebuild is the new bitmaps; the directory tuning isn't needed as part of ext4
[09:43] <lifeless> poolie: [sometimes it pays to ask paranoid questions :P]
[09:44] <poolie> oh
[09:44] <lifeless> poolie: anyhow, that make_indexed_dir isn't part of the new ext4 features; it does sound alarming though.
[09:44] <poolie> actually I did not use -0
[09:44] <poolie> it sounds like an ext3 thing
[09:44] <apw_> # tune2fs -O extents,uninit_bg,dir_index /dev/sdb1
[09:44] <apw_> is that the one you turned on?
[09:45] <poolie> actually it was http://kernelnewbies.org/Ext4
[09:45] <poolie> so extents,uninit_bg,dir_index
[09:45] <poolie> and then fsck -CDf
[09:45] <lifeless> you probably had dir_index already, knoowing your machines
[09:46] <poolie> yes, i probably did
[09:47] <apw_> hrm, that would explain why you are the first to be mentioning it.  you should record that in the box
[09:47] <apw_> bug even
[09:48] <lifeless> apw_: I don't think its related; I *know* I had dir_index on - and nearly all ubuntu upgrades to ext4 will have had dir_index on.
[09:48] <lifeless> we turned it on by default about 4? years back
[09:48]  * apw_ checks his
[09:50] <apw_> Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
[09:52] <poolie> it's in /etc/mke2fs.conf or something
[09:52] <lifeless> apw_: looks about right to me
[09:58] <poolie> apw_: so i should probably leave and have dinner in a sec 
[09:59] <poolie> if this is not just a glitch it seems like a bad bug so i'd like to help it get solved
[09:59] <poolie> is there anything else i can do?
[10:00] <lifeless> poolie: have you done another fsck? (just -f, no -D)
[10:00] <poolie> yes, see the bug
[10:00] <lifeless> poolie: ok, sorry :>
[10:00] <poolie> many errors, which it won't fix with -p
[10:00] <apw_> ok ... thanks for the report
[10:16] <lifeless> apw: can I run something by you ?
[10:16] <lifeless> when I run iotop
[10:16] <lifeless> I get 'CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO %'
[10:18] <apw> yep, that one seemed to have a measurable cost i think
[10:19] <lifeless> ><
[10:19] <lifeless> is there a kernel with it on ? was very useful for figuring out what apps are being bad
[10:20] <lifeless> the other thing is, do we build debug packages for the kernel? for use with oprofile?
[10:20] <lifeless> years ago I filed a bug asking for this, and we started, but I can't seem to find them now...
[10:22] <apw> i don't think we have a kerel with it on no
[10:22] <apw> the debug packages are in the ddebs.ubuntu.com archive
[10:26] <lifeless> apw: ok cool
[10:26] <lifeless> thanks
[10:26] <lifeless> apw: you might want to close the bug I opened about DELAY_ACCT then :>
[10:27] <apw> there was some discussion about it on kernel-team, not sure if it got bottomed out on or not
[12:29] <jxiong> hello
[12:29] <jxiong> folks, I spent several hours to try to find the vmlinux file for my laptop
[12:29] <jxiong> do you have any ideas?
[12:29] <jxiong> Linux ubuntu 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28 02:39:34 UTC 2010 x86_64 GNU/Linux
[12:30] <nigel_c> Should be in /boot/vmlinuz-2.6.31.19-generic
[12:30] <smb> jxiong, Have you tried ddebs.ubuntu.com ? There should be ddeb packages for kernels
[12:30] <jxiong> smb: yes, I tried.
[12:31] <jxiong> it doesn't include something like linux-image-XXX-debug/dbgsym..
[12:32] <nigel_c> apt-file search /boot/vmlinuz-2.6.31.19-generic?
[12:34] <jxiong> nigel_c: thank you, what I'm searching for is vmlinux, which includes debug info
[12:35] <jxiong> vmlinuz is an executable image, it's a compressed binary code
[12:38] <nigel_c> I'm pretty sure all the Ubuntu kernels have the config options enabled that include debugging info, so you should just be able to run gdb on any vmlinux. Vmlinuz is just the same thing gzipped IIRC.
[12:39] <smb> As the pre-compiled seem to have vanished again, the only way seems to "apt-get source ..." the linux-image source and the compile it yourself :(
[12:41] <jxiong> what a pity
[13:17] <apw> Keybuk, hey ... i am struggling to get you the page numbers for pages you don't have mapped
[13:18] <apw> ie. as you don't have the pages actually present in ureadahead you don't have the pfn numbers so you don't have the pfn's to lookup kpageflags
[13:18] <Keybuk> apw:  how do you mean?
[13:18] <Keybuk> mmap maps the pages, no?
[13:18] <apw> no they are not present as you have never referenced them
[13:19] <apw> so you don't have them in your pagemaps to map ... blah
[13:19] <apw> now i think i have a different way round this
[13:19] <apw> i think i can return the additional info in the mincore result
[13:19] <apw> which brings me to the fact i think you have  a bug in your mincore use
[13:19] <apw> as you for if (!vec[x]) 
[13:20] <apw> but the manual says you can't do that, you can only rely on the value of bit 0
[13:20] <apw> i suspect returning that information in mincore would be pretty handy for you
[13:20] <apw> but ... it does rely on all users of mincore reading the manual page
[13:21] <apw> Keybuk, what do you think
[13:22] <Keybuk> sounds reasonable
[13:23] <Keybuk> someone changed the mincore() manpage <g>
[13:23] <apw> that interface seems to only allow me to return very small amounts of info, no more than a few bits, which makes it hard to return anything more than 'used/unused'
[15:46] <manjo> apw, http://voices.canonical.com/kernelteam/
[15:46] <manjo> smb, http://voices.canonical.com/kernelteam/
[15:57] <apw> Keybuk, hey how is that plymouth race the one which leads to 'return' being fatal ... who has that?
[15:57] <Keybuk> I have the ball on that one
[15:57] <Keybuk> though it's your fault, you and your buggy kernel
[15:58] <apw> excellent ... whats wrong with my beautiful kernel :)
[15:59] <smb> apw, apparently sound
[16:03] <manjo> \http://www.sonystyle.com/webapp/wcs/stores/servlet/ProductDisplay?storeId=10151&catalogId=10551&langId=-1&productId=8198552921665974276
[16:06] <cnd> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ec67bbedcf290ef182a897017f65a2707106c7f8
[16:17] <tjaalton> cnd: probably needs the other two commits for 1.52 as well?
[16:19] <apw> then its probabally too big for lucid
[16:19] <cnd> tjaalton: I'm going to try to build a module with just that commit to see if it works
[16:19] <cnd> but yeah, that commit alone is pretty huge
[16:20] <tjaalton> this one looks quite sensible to me
[16:20] <tjaalton> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=232f5693e5c9483e222528ef81979e42ea2f2908
[16:22] <cnd> tjaalton: we tend to just backport fixes, so unless this fixes a bug people are having we probably won't backport it
[16:22] <tjaalton> sooner or later they will ;)
[16:23] <cnd> cnd, it may, but it may also introduce more issues
[16:23] <apw> linux-image-2.6.32-15-generic-debug_2.6.32-15.21~ddebrenameapw1_i386.ddeb
[16:23] <apw> smb, ^^
[16:23] <cnd> so we have to be judicious
[16:26] <tjaalton> that patch needs at least this one http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ec67bbedcf290ef182a897017f65a2707106c7f8
[16:26] <tjaalton> or manual backporting, of course
[16:26] <cnd> tjaalton: yes, that's the same that I posted above
[16:27] <tjaalton> uh, damn
[16:27] <cnd> I'm going to build a module with just that commit
[16:27] <tjaalton> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ee54500d7b960984df125bdd0cd2105d6150e8f1
[16:27] <tjaalton> this one
[16:27] <cnd> tjaalton: I assume you have hw for this?
[16:27] <tjaalton> no
[16:27] <tjaalton> well, I have an intuos4
[16:27] <tjaalton> but not the new stuff
[16:27] <cnd> tjaalton: would you mind testing a module if I get one built?
[16:27] <tjaalton> cnd: sure
[16:28] <apw>   INSTALL debian/-generic/usr/lib/debug/lib/firmware/yam/1200.bin
[16:28] <smb> seems to be missing somethign
[16:28] <cnd> tjaalton: please subscribe to bug 516777, I'll post the stuff there
[16:28] <ubot3> Malone bug 516777 in linux "HP Touchsmart tm2 requires newer wacom driver" [Low,Triaged] https://launchpad.net/bugs/516777
[16:30] <tjaalton> cnd: you mean to test it doesn't break mine?
[16:30] <cnd> tjaalton: yes
[16:30] <cnd> I'll post a test module to that bug
[16:30] <tjaalton> cnd: right, might as well upgrade the desktop to lucid then (and test that suspend thing :)
[16:37] <bjf> smb, ring me back please
[17:08] <cnd> smb, tjaalton, apw: test module is up at http://people.canonical.com/~cndougla/516777/wacom.ko
[17:22] <Keybuk> apw: am I missing something here?
[17:22] <Keybuk> the mainline 2.6.33 build is missing devtmpfs
[17:22] <manjo> smb, apw cnd I am dropping off 
[17:24] <apw> Keybuk, ahh ... its beacuse its being built on karmic ... 
[17:25] <Keybuk> apw: FAIL
[17:25] <apw> well it depends what you think they are for
[17:25] <apw> originally they were for testing on karmic... what it highlights is we need them to be built for both
[17:26] <apw> or ... more specifically ... they are built for one ... which one needs to be part of that information
[17:27] <Keybuk> happily it proves you can still boot lucid without devtmpfs <g>
[17:28] <apw> yeah just about, slow as hell mind
[17:28] <apw> i'll have a think about what we should be doing there over beer tonight
[17:28] <apw> i don't want to have to build them all twice, that would suck
[17:31] <cnd> smb, tjaalton, apw: http://people.canonical.com/~cndougla/516777/i386/wacom.ko if you need it
[17:32] <cnd> http://people.canonical.com/~cndougla/516777/amd64/wacom.ko for amd64 (I moved it)
[17:33] <smb> cnd, Sorry to be wincing. The i386 is for 2.6.31-13... :(
[17:33] <cnd> smb: what?
[17:34] <cnd> grrr... how did that happen
[17:36] <smb> ok, its 2.6.32-13
[17:41] <cnd> smb: should be better now
[17:41]  * smb looks
[17:59] <Keybuk> apw: if I want to apply a patch to one of your mainline linux-source packages
[17:59] <Keybuk> what do I have to do to stop the ABI checker eating me?
[18:00] <apw> the mainline builds i think they are disabled in there
[18:01] <apw> check the check-abi script to see whats in it
[18:01] <Keybuk> ok
[18:01] <Keybuk> http://people.freedesktop.org/~glisse/0001-drm-radeon-kms-initialize-set_surface_reg-reg-for-rs.patch
[18:01] <Keybuk> this may end up on kernel-team if it works
[18:07] <Keybuk> apw: argh
[18:07] <Keybuk> in fact
[18:07] <Keybuk> where *IS* the source package for mainline builds?
[18:07] <apw> supposed to be with them
[18:07] <Keybuk> isn't
[18:07] <Keybuk> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33/
[18:08] <apw> there is a 64mb source package there
[18:08] <Keybuk> no there isn't
[18:08] <Keybuk> there's no .dsc or .tar.gz
[18:08] <Keybuk> there's a deb that contains a tarfile
[18:08] <Keybuk> but that *does not contain the debian directory or the config*
[18:08] <apw> it doesn't ?
[18:08] <Keybuk> no
[18:09] <apw> well just checkout the one in our git tree into it
[18:09] <Keybuk> example command?
[18:09] <toabctl> hi
[18:09] <toabctl> can anybody help with bug #527912 ?
[18:09] <ubot3> Malone bug 527912 in xf86-input-wacom "Wacom Bamboo CTH-661 not recognized" [Undecided,New] https://launchpad.net/bugs/527912
[18:09] <apw> git checkout origin/master debian debian.master
[18:09] <Keybuk> apw: there's no .git either
[18:10] <apw> so copy the debian* out of the lucid git tree
[18:11] <Keybuk> will that work?
[18:11] <Keybuk> all the changelog and versions and abis will be all wrong
[18:11] <Keybuk> and it'll vomit the install
[18:11] <apw> do you need that patch in .33 or in lucid ?
[18:11] <Keybuk> I need to test the patch
[18:11] <apw> if you want me to build you one
[18:12] <Keybuk> I'm going to try and build off lucid
[18:12] <Keybuk> that seems easiest
[18:12] <Keybuk> I know how to do that <g>
[18:12] <apw> yeah probabally is :)
[18:13] <apw> toabctl, which release are you runningn
[18:13] <toabctl> apw, lucid
[18:13] <toabctl> apw, there changed something with wacom drivers
[18:13] <apw> did it work before on karmic?
[18:14] <toabctl> apw, i don't now. the board is 2 days old:)
[18:14] <apw> so it may not be a supported version then
[18:14] <apw> what usbid's does it have
[18:14] <toabctl> apw, how can i get the usb id?
[18:15] <apw> lsusb
[18:15] <toabctl> apw, i think it should work with http://linuxwacom.sourceforge.net/index.php/main but this drivers only support xserver <= 1.6
[18:15] <toabctl> apw, Bus 001 Device 010: ID 056a:00d3 Wacom Co., Ltd
[18:16] <toabctl> apw, where's the place to find the usb-id <-> driver mapping?
[18:17] <tjaalton> toabctl: the thing is that the X driver isn't being loaded for the device
[18:18] <toabctl> tjaalton, and how can i fix this? maybe the driver supports the board...
[18:18] <tjaalton> udevadm info --export-db
[18:18] <tjaalton> attach that to the bug
[18:19] <tjaalton> (need to add an apport hook for xf86-input-wacom)
[18:19] <apw> tjaalton, we probabally should get that for kernel bugs too
[18:20] <toabctl> tjaalton, added: see http://launchpadlibrarian.net/39785696/udevadm_info.txt
[18:20] <tjaalton> apw: yeah
[18:21] <apw> tjaalton, so does X input handle those direct?
[18:21] <tjaalton> apw: via udev, yes. but they also need the kernel module for fancy features
[18:22] <tjaalton> toabctl: thanks
[18:22] <apw> ok ... so it may or may not work
[18:22] <tjaalton> I need to check the list for bamboo
[18:22] <tjaalton> toabctl: has it ever worked?
[18:22] <toabctl> tjaalton, no. i got it 2 days ago
[18:23] <toabctl> tjaalton, but there are comments on the web that i worked with karmic 
[18:23] <tjaalton> huh, ok
[18:24] <tjaalton> but it's a different driver on lucid, so something might be missing
[18:24] <toabctl> tjaalton, the problem is (i think), that the wacom stuff changed completely with lucid (see alpha-2 release notes)
[18:24] <tjaalton> like the udev rules for it
[18:24] <tjaalton> oh really? :)
[18:24] <tjaalton> (I know)
[18:24] <toabctl> tjaalton, yes. hopefully just a udev rule is missing :)
[18:26] <toabctl> tjaalton, the device is available in the output of udevadm. but what can i do now?
[18:28] <tjaalton> toabctl: just wait for now
[18:29] <toabctl> tjaalton, how long ?:-)
[18:29] <bjf> toabctl, if it was working in karmic and you need the tablet, run karmic
[18:30] <tjaalton> it doesn't have any ID_INPUT* stuff listed, so figuring out why input_id is not run
[18:30] <bjf> toabctl, keep testing lucid alpha/beta releases and see when it gets fixed
[18:30] <toabctl> bjf, i don't need the tablet. i'll give it back if it will not work in 2 weeks.
[18:30] <toabctl> bjf, but i like to find out if it's possible that the tablet does the job.
[18:31] <tjaalton> toabctl: could be that the kernel doesn't know it yet, otherwise it should be in the input subsystem I think
[18:31] <bjf> toabctl, you could try a karmic live-cd image and see if it works
[18:32] <manjo> JFo, bjf, applied you kernel-qa / tests patch and I implemented progress bar 
[18:32] <manjo> JFo, bjf I will check in soon
[18:33] <JFo> ok
[18:36] <toabctl> tjaalton, in /lib/udev/rules.d/69-xserver-xorg-input-wacom.rules is no line for the id 056a:00d3 . maybe that's the problem? i don't know much about udev rules..
[18:36] <tjaalton> toabctl: check bug 522318, there are new rules for a similar case where the subsystem is 'pnp'
[18:36] <ubot3> Malone bug 522318 in xorg-server "Serial Tablet PCs not supported in lucid" [Medium,Fix committed] https://launchpad.net/bugs/522318
[18:36] <tjaalton> toabctl: partly correct
[18:37] <tjaalton> toabctl: I'll add something to the bugreport for you to try..
[18:37] <toabctl> tjaalton, ok. thx
[18:52] <tjaalton> toabctl: yeah I don't think wacom supports it yet, properly anyway. can't find the id from wacom_wac.c
[18:52] <tjaalton> toabctl: is it the "pen & touch"
[18:52] <tjaalton> ?
[18:53] <toabctl> tjaalton, yes. pen & touch
[18:53] <toabctl> tjaalton, some people say it works: see http://aur.archlinux.org/packages.php?ID=31540
[18:54] <tjaalton> ok, those patches are not upstream then
[19:03] <tjaalton> toabctl: there's a huge thread on linuxwacom-discuss about it
[19:04] <toabctl> tjaalton, can give paste me a link ?
[19:04] <tjaalton> the support might be in linuxwacom, but not yet in xf86-input-wacom..
[19:04] <toabctl> tjaalton, and why does ubuntu no more supports linuxwacom?
[19:05] <tjaalton> toabctl: because it doesn't work with xserver 1.7
[19:05] <toabctl> and where is the source of xf86-input-wacom? the source package has as homepage http://linuxwacom.sf.net
[19:05] <tjaalton> xf86-input-wacom is the way forward
[19:05] <tjaalton> http://linuxwacom.git.sourceforge.net/git/gitweb.cgi?p=linuxwacom/xf86-input-wacom;a=summary
[19:07] <toabctl> tjaalton, in the git repository is xf86-input-wacom-0.10.4 available, but the ubuntu packages has 0.10.3
[19:08] <tjaalton> right
[19:08] <tjaalton> the driver itself support it, as it turns out
[19:08] <tjaalton> but not the kernel component
[19:08] <cnd> bdmurray: re the wacom stuff, which arch did you test?
[19:09] <bdmurray> amd64
[19:09] <tjaalton> toabctl: maybe best to continue on ubuntu-x ->
[19:09] <manjo> bjf, I pushed your changes and added progress indicator to copying log files 
[19:09] <manjo> JFo, ^^
[19:09] <toabctl> tjaalton, i asked on ubuntu-x, but nobody answered.
[19:09] <JFo> cool, thanks manjo 
[19:10] <tjaalton> toabctl: because you were having the discussion here already :)
[19:11] <toabctl> ok. switch talk to #ubuntu-x
[19:13] <cnd> bdmurray: can you paste uname -a?
[19:15] <bdmurray> Linux artemis 2.6.32-14-generic #20-Ubuntu SMP Sat Feb 20 05:18:19 UTC 2010 x86_64 GNU/Linux
[19:16] <bjf> manjo, two thoughts...
[19:16] <cnd> apw, smb, do you know what would cause this when running insmod: wacom: no symbol version for module_layout
[19:16] <bjf> manjo, one: I'd like to see all the log collection in a single function so it's real obvious where the log collection is happening
[19:17] <manjo> bjf, did you see the changes I made after yours ?
[19:17] <bjf> manjo, yes
[19:17] <smb> cnd, I assumed it was my non-standard kernel. I would say it requires and external function module_layout
[19:17] <manjo> so copy_files() does all the copying ie log collection .. 
[19:17] <cnd> smb, could it be because I didn't build the whole kernel?
[19:18] <cnd> just the drivers/input/tablet directory?
[19:18] <smb> cnd, It might be
[19:18] <bjf> manjo, no copy_files does the copy and the ui, I'd like to see the calls to copy_files in a single function "capture_logs" or some such
[19:18] <manjo> ?
[19:19] <cnd> smb, bdmurray: I'm going to try to rebuild the entire kernel and put up the resulting kernel, let's see how well that works
[19:19] <bdmurray> cnd: okay
[19:19] <apw> cnd it may well be yes.  its something modpost makes
[19:19] <smb> cnd, you still might be able to just put up the module
[19:19] <apw> scripts/mod/modpost.c:          mod->unres = alloc_symbol("module_layout", 0, mo
[19:19] <bjf> manjo, lines 251 - 260
[19:19] <cnd> smb, yeah, that's what I plan
[19:19] <smb> cnd, I guess you just need the full compile to get a version function
[19:19] <smb> versioned function
[19:20] <manjo> bjf, oh ic 
[19:20] <manjo> bjf, send me a patch
[19:20] <manjo> bjf, I think that is a good point 
[19:20] <bjf> manjo, actually I'm thinking I'd like the log and system information captured in a separate script which I could call without having to run the test
[19:20] <bjf> manjo, what do you think of that?
[19:21] <bjf> that may not have been very clear
[19:21]  * manjo thinking ... 
[19:21] <manjo> we can have it in a separate script 
[19:22] <manjo> and source that script and use the function in kernel-qa as well
[19:22] <bjf> manjo, the copy is happening at the very beginning, 
[19:22] <manjo> so in kernel-qa you could do source new_script
[19:22] <bjf> hmmm
[19:23] <manjo> in case we want to use copy_files() anywhere 
[19:23] <bjf> manjo, I'm running it right now and the progress bar has "[sudo] password for bradf:" in it
[19:23] <manjo> yeah you are supposed to run sudo ./kernel-qa
[19:23] <manjo> bjf, just type your passwd
[19:24] <manjo> bjf, this is coz we have a sudo less environment usually
[19:26] <manjo> bjf, I am also thinking of adding a function like ... exec_with_progress() .. so you can call it like exec_with_progress "somecmd parameters"
[19:26] <bjf> manjo, if you put a "sudo date" before the first "copy_files" then the user is prompted for the password before the dialog comes up
[19:26] <manjo> from the test case 
[19:26] <manjo> bjf, no I should ask for the password in a dialog box 
[19:27] <manjo> bjf, and I know how to do that 
[19:27] <manjo> bjf, I did not do it coz we have passwd less env... but that is not good if we want to have it generic 
[19:27] <bjf> manjo, why do you need to ask for it in a dialog box?
[19:28] <manjo> bjf, so if you run ./kernel-qa it will ask for your passwd
[19:28] <manjo> or kernel-qa needs to be installed with uid root 
[19:29] <bjf> manjo, yes, and if you'd just put the "sudo date" as the first thing you get to type in your password and then the ui comes up
[19:29] <bjf> it's simple
[19:29] <manjo> ok
[19:30] <manjo> bjf, dialog --passwordbox does it in a fancy way 
[19:31] <bjf> manjo, I was looking at some bugs and I've noticed that checkbox is gathering hw information in an interesting way that we might look at
[19:32] <manjo> bjf, :) we might just recreate checkbox finally 
[19:32] <bjf> manjo, not intereted in that however, the hwinformation did look interesting, just a sec I'll get you a bug #
[19:33] <manjo> bjf, I know what you are taking about 
[19:33] <manjo> bjf, hwinfo and pciutils are not installed by default on servers for example 
[19:33] <manjo> bjf, and its painful to deal with it coz checkbox croaks
[19:33] <manjo> bjf, not that I am agianst the idea of looking into it ... just letting you know 
[19:34] <bjf> manjo, then I don't think you know what I'm talking about
[19:34] <manjo> ok]
[19:34] <manjo> point me to bug please
[19:34] <bjf> manjo, bug 399319
[19:35] <ubot3> Malone bug 399319 in checkbox "Remove the HAL dependency from Launchpad HWDB and checkbox " [Medium,Fix released] https://launchpad.net/bugs/399319
[19:36] <bjf> manjo, they are processing "udevadm info --export-db" and "grep -r . /sys/class/dmi/id/ 2>/dev/null" and "devkit-disks --dump"
[19:36] <manjo> bjf, udevadm info --export-db
[19:36] <manjo> yep we can have that 
[19:37] <manjo> they changed to it after me bitching about it for 1yr
[19:37] <bjf> manjo, but I think you want to look at how checkbox does it because I believe he combines it all into an xml file and submits it as a single xml blob
[19:38] <bjf> manjo, I'd like to get it in the exact same format
[19:38] <manjo> bjf, sure, you want to do it :)
[19:41] <bjf> manjo, I'll look into it, it won't get done right away
[19:41] <manjo> sure, I don't understand fancy langs like xml
[19:41] <bjf> manjo, I was looking at it last night and his code is shit to follow
[19:41] <manjo> :) lol
[19:42] <manjo> bjf, I have had to ceal with it for 1.3yrs now 
[19:42] <manjo> deal
[19:42] <manjo> bjf, and I am no way python expert
[19:43] <manjo> bjf, its more fun when it blows up in front of imp people ... and you are scrambling to fix it 
[19:44] <manjo> apw, you still around ? 
[19:48] <manjo> apw, I have an aspire one that boots from USB stick to a blinking cursor :) 
[20:13] <cnd> bdmurray: still around? can you test out the amd64 wacom module?
[20:13] <cnd> I just uploaded a new one to the same location
[20:14] <bdmurray> cnd: yes, testing
[20:17] <bdmurray> cnd: works great!
[20:17] <cnd> bdmurray: it both loads AND it works for your wacom tablet?
[20:17] <bdmurray> cnd: yes
[20:18] <cnd> bdmurray: great! please log your results in the bug
[20:18] <cnd> I still don't know whether we'll be able to put it into lucid, we'll at least need more testing
[20:18] <cnd> cause the changes are rather expansive
[20:18] <cnd> but we can look into other options if not
[21:14] <LLStarks> apw, quick question. why isn't the kernel ppa an actual ppa?
[21:42] <cnd> LLStarks: apw is likely gone for the day, which ppa are you referring to?
[21:42] <LLStarks> the mainline kernel ppa
[21:45] <cnd> LLStarks: hmmm... I'm guessing the reason is that no one ever really runs it as a ppa?
[21:45] <cnd> I'm not really sure
[21:45] <LLStarks> that would save me 4 wgets and dpkgs
[21:46] <LLStarks> well, manual operations.
[22:00] <cnd> LLStarks: why four?
[22:00] <LLStarks> headers. image. generic.
[22:00] <Q-FUNK> hi!
[22:01] <LLStarks> headers all.
[22:01] <LLStarks> wait.
[22:01] <LLStarks> damn.
[22:01] <LLStarks> headers. header generic. source. image.
[22:01] <cnd> oh, yeah
[22:02] <cnd> LLStarks: do you run mainline all the time?
[22:02] <LLStarks> not always.
[22:02] <LLStarks> breaks things from time to time.
[22:02] <Q-FUNK> what kernel .config option do I need to have root=UUID work on cmdline?   I'm attempting to build my own minimal kernel as a test to debug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/396286
[22:02] <ubot3> Malone bug 396286 in linux "[Geode LX] [OLPC] 2.6.31-generic: kernel panic near the end of initramfs" [High,In progress] 
[22:06] <cnd> Q-FUNK: if you are doing testing, it may be easier to just use root=/dev/sd??
[22:06] <cnd> instead of using UUID
[22:06] <cnd> unless the UUID is particular to that bug
[22:07] <Q-FUNK> cnd: it works with that, but then I constantly have to manually fix menu.lst
[22:07] <mjg59> Also, the kernel doesn't parse that
[22:07] <cnd> Q-FUNK: ahhh, have you looked at the differences between your kernel config and the ubuntu kernel config?
[22:08] <cnd> that may tell you
[22:08] <Q-FUNK> mjg59: doesn't parse what?
[22:09] <mjg59> Q-FUNK: root=uuid
[22:09] <cnd> mjg59: it parses something like root=UUID=299e7785-7c3d-4e90-9779-239cb237a4d2
[22:10] <mjg59> Fairly sure that's done by initramfs
[22:10] <Q-FUNK> mjg59: ok.  does ubuntu have a magic hack that converts something like root=UUID=299e7785-7c3d-4e90-9779-239cb237a4d2 to what the kernel expects?
[22:11] <cnd> mjg59: yes, you're right
[22:11] <cnd> Q-FUNK: how are you building your kernel?
[22:11] <mjg59> Q-FUNK: No, it just does it itself
[22:12] <mjg59> Which means it probably won't work unless you build with a ramdisk
[22:12] <Q-FUNK> kernel-package, with the option --initrd
[22:13] <cnd> Q-FUNK: I'm not too familiar with using kpkg, unfortunately
[22:14] <cnd> I build kernels through the process described at: https://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter
[22:14] <cnd> someone else may be able to help you with kpkg
[22:42] <mjg59> Which means it probably won't work unless you build with a ramdis4
[22:42] <mjg59> Oops.
[22:49] <Q-FUNK> ogasawara: seems that I have a winner.  something that gets included in the initrd.img is what causes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/396286
[22:49] <ubot3> Malone bug 396286 in linux "[Geode LX] [OLPC] 2.6.31-generic: kernel panic near the end of initramfs" [High,In progress] 
[22:50] <Q-FUNK> only, I have no idea what exactly.
[22:51] <mjg59> Q-FUNK: Hack initramfs-tools and add set -x to the top of it in order to see what's executing and when?
[22:51] <Q-FUNK> mjg59: that sounds like a plan.  let's see if I can find the right file to hack for this.
[22:58] <lifeless> there is a verbose mode
[22:58] <lifeless> update-initramfs -u -v
[23:38] <Q-FUNK> ogasawara: bug report updated.  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/396286  hopefully smb can make something out of it. :)
[23:38] <ubot3> Malone bug 396286 in linux "[Geode LX] [OLPC] 2.6.31-generic: kernel panic near the end of initramfs" [High,In progress]