=== yofel_ is now known as yofel [02:15] fyi the http access method of the ubuntu-oneiric.git repo is out of date [04:04] what's the "ref" in "linux-header-3.0.0-12-ref-generic" ? [06:01] <_ruben> hrm .. is $ARCH supposed to be amd64 or x86_64 on a 64bits -server system? apparently it should be x86_64, but i got systems where it's amd64 which breaks (out of tree) kernel (module) compiles [06:06] <_ruben> yet uname -m yields x86_64 just fine... strange [06:12] the arch name changed a looong time ago when the arch's were combined under x86 [06:12] <_ruben> and this being on lucid, i really wonder where it's getting the amd64 stuff from [06:17] <_ruben> adding export ARCH=$(uname -m) to debian/rules seems to work, but is rather nasty :) === smb` is now known as smb [07:37] morning [07:37] _ruben, the kernel arch and the debian arch differ [07:37] but the rules should be handling it if your are using them the way the Debian gods intended [07:38] smb, morning [07:59] morning * [08:04] ppisati, moin [08:07] yawn [08:33] cking, morning [08:49] * apw waves to cking [08:50] * apw notes that he sees a helicopter every time he says your name [08:50] cking [08:51] (nope, no helicopter. Must be a London thing) [08:53] heh [08:53] apw, As long as there are no people in black dangling from it into you room... [08:53] no this is entirly in my head thankfully [09:42] * ppisati bails out for a bit... [09:47] helicopters? [09:48] sea-king ? [09:49] https://secure.wikimedia.org/wikipedia/en/wiki/Westland_Sea_King [09:51] Gnome engines... :-) [10:58] droll [12:34] jk-, that was what i was aluding to yes [12:35] ppisati, you have this work-item ope [12:35] open "[p-pisati] look into generating a trimmed down config for debug purposes (maybe discuss at the platform sprint): TODO [12:35] any idea what it is about and what we ahould do with it [12:36] apw: it wasn't really an action [12:36] apw: i was looking for some useful configs for debugging [12:37] apw, we discussed it last arm meeting, i thought i asked ppisati tzo close it [12:37] (close as in POSTPONE to P) [12:38] we will definitely have kernel config sync meertings at UDS for arm [12:39] postponed [12:53] ogra_, ppisati, thanks [13:43] * ogasawara back in 20 === tgardner is now known as tgardner-afk === tgardner-afk is now known as tgardner [16:32] * apw is going to wander somewhere sunnier and enjoy the outside for a bit ... and think about quirks [16:45] how quirky [17:50] * tgardner -> lunch [18:38] hi folks, I'd appreciate some help to understand some of the devices output by udevadm: I'm looking at a webcam which seems to have two entries, one on the usb and another one on the input subsystem. what's the difference? [19:52] is there a recommended way to determine the number bits per long based on information gathered from a system? for example, if I rely in uname -m, is there a reference table mapping all the known machine types to the number of bits per long? [20:00] cr3: [20:00] int main() { [20:00] printf("long is %d bytes\n", sizeof(long)); [20:00] } [20:00] cr3, perhaps do some hackery with gcc ? [20:00] dannf, :) [20:02] dannf: based on information gathered though and I'd rather not have to compile something just to gather that information, something that apport could report for example [20:03] tgardner: indeed, perhaps I could get that information with some gcc magic on the command line, but I'd be more inclined to build my own table from the output of uname -m even though I hate building my own tables :( [20:04] cr3, dpkg-architecture ? DEB_HOST_ARCH_BITS=64 [20:04] dannf: for example, lets say apport already reports dmesg or udev information, so might there be heuristics to extrapolate the bits per long from that information? [20:05] tgardner: I like it! [20:05] cr3: seems tricky in the bi/multi arch world. uname -m is from the kernel - but you can run architectures that support 4 or 8 bytes per long on it [20:05] cr3, requires dpkg-dev [20:05] depends on what you're after of coures [20:06] doesn't sparc64 have 4-byte longs? [20:06] oh, maybe not [20:06] meh [20:07] dannf: very good point, I'm after the KEY= part output by udevadm where "10000 0 0 0 0" might refer to very different bits depending on the bits per long. that's a kernel thing though, so uname -m would aptly correspond to the output of udev [20:08] tgardner: I like less dpkg-dev but I'll certainly have a look at the source just in case it provides another hint [20:09] err, I like less *depending on* dpkg-dev... I do like dpkg-dev :) [20:11] rapture! /usr/share/dpkg/cputable [20:12] * jjohansen -> lunch/run [20:13] that is one freaking useful table, x86_64 vs amd64 always annoyed me but this table makes for a meaningful conversion between the two [20:13] cr3, glad we could help :) [20:14] gotta go [20:14] tgardner: always a pleasure hanging around here, although a bit too silent... must be because it's hard to type while holding a beer in one hand [20:15] lol [20:51] ogasawara, can you check into bug 710733 [20:51] Launchpad bug 710733 in linux "LKCD Not Executing kexec Properly" [High,Confirmed] https://launchpad.net/bugs/710733 [20:55] in the end, did we decide that there wasn't actually any easier way to get the umask for process N than to attach to it with gdb and p umask(0) ?