[02:15] <Tv__> fyi the http access method of the ubuntu-oneiric.git repo is out of date
[04:04] <Tv__> 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] <ohsix> 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 :)
[07:37] <smb> morning
[07:37] <apw> _ruben, the kernel arch and the debian arch differ
[07:37] <apw> but the rules should be handling it if your are using them the way the Debian gods intended
[07:38] <apw> smb, morning
[07:59] <ppisati> morning *
[08:04] <apw> ppisati, moin
[08:07] <cking> yawn
[08:33] <smb> 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] <amitk> cking
[08:51] <amitk> (nope, no helicopter. Must be a London thing)
[08:53] <apw> heh
[08:53] <smb> apw, As long as there are no people in black dangling from it into you room...
[08:53] <apw> no this is entirly in my head thankfully
[09:42]  * ppisati bails out for a bit...
[09:47] <cking> helicopters?
[09:48] <jk-> sea-king ?
[09:49] <jk-> https://secure.wikimedia.org/wikipedia/en/wiki/Westland_Sea_King
[09:51] <smb> Gnome engines... :-)
[10:58] <cking> droll
[12:34] <apw> jk-, that was what i was aluding to yes
[12:35] <apw> ppisati, you have this work-item ope
[12:35] <apw> open "[p-pisati] look into generating a trimmed down config for debug purposes (maybe discuss at the platform sprint): TODO
[12:35] <apw> any idea what it is about and what we ahould do with it
[12:36] <ppisati> apw: it wasn't really an action
[12:36] <ppisati> apw: i was looking for some useful configs for debugging
[12:37] <ogra_> apw, we discussed it last arm meeting, i thought i asked ppisati tzo close it
[12:37] <ogra_> (close as in POSTPONE to P)
[12:38] <ogra_> we will definitely have kernel config sync meertings at UDS for arm
[12:39] <ppisati> postponed
[12:53] <apw> ogra_, ppisati, thanks
[13:43]  * ogasawara back in 20
[16:32]  * apw is going to wander somewhere sunnier and enjoy the outside for a bit ... and think about quirks
[16:45] <cking> how quirky
[17:50]  * tgardner -> lunch
[18:38] <cr3> 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] <cr3> 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] <dannf> cr3:
[20:00] <dannf> int main() {
[20:00] <dannf>   printf("long is %d bytes\n", sizeof(long));
[20:00] <dannf> }
[20:00] <tgardner> cr3, perhaps do some hackery with gcc ?
[20:00] <tgardner> dannf, :)
[20:02] <cr3> 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] <cr3> 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] <tgardner> cr3, dpkg-architecture ? DEB_HOST_ARCH_BITS=64
[20:04] <cr3> 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] <cr3> tgardner: I like it!
[20:05] <dannf> 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] <tgardner> cr3, requires dpkg-dev
[20:05] <dannf> depends on what you're after of coures
[20:06] <mdeslaur> doesn't sparc64 have 4-byte longs?
[20:06] <mdeslaur> oh, maybe not
[20:06] <mdeslaur> meh
[20:07] <cr3> 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] <cr3> 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] <cr3> err, I like less *depending on* dpkg-dev... I do like dpkg-dev :)
[20:11] <cr3> rapture! /usr/share/dpkg/cputable
[20:12]  * jjohansen -> lunch/run
[20:13] <cr3> 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] <tgardner> cr3, glad we could help :)
[20:14] <tgardner> gotta go
[20:14] <cr3> 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] <mdeslaur> lol
[20:51] <pgraner> ogasawara, can you check into bug 710733
[20:51] <ubot2> Launchpad bug 710733 in linux "LKCD Not Executing kexec Properly" [High,Confirmed] https://launchpad.net/bugs/710733
[20:55] <lamont> 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) ?