=== yofel_ is now known as yofel
Tv__fyi the http access method of the ubuntu-oneiric.git repo is out of date02:15
Tv__what's the "ref" in "linux-header-3.0.0-12-ref-generic" ?04:04
_rubenhrm .. 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) compiles06:01
_rubenyet uname -m yields x86_64 just fine... strange06:06
ohsixthe arch name changed a looong time ago when the arch's were combined under x8606:12
_rubenand this being on lucid, i really wonder where it's getting the amd64 stuff from06:12
_rubenadding export ARCH=$(uname -m) to debian/rules seems to work, but is rather nasty :)06:17
=== smb` is now known as smb
apw_ruben, the kernel arch and the debian arch differ07:37
apwbut the rules should be handling it if your are using them the way the Debian gods intended07:37
apwsmb, morning07:38
ppisatimorning *07:59
apwppisati, moin08:04
smbcking, morning08:33
* apw waves to cking08:49
* apw notes that he sees a helicopter every time he says your name08:50
amitk(nope, no helicopter. Must be a London thing)08:51
smbapw, As long as there are no people in black dangling from it into you room...08:53
apwno this is entirly in my head thankfully08:53
* ppisati bails out for a bit...09:42
jk-sea-king ?09:48
smbGnome engines... :-)09:51
apwjk-, that was what i was aluding to yes12:34
apwppisati, you have this work-item ope12:35
apwopen "[p-pisati] look into generating a trimmed down config for debug purposes (maybe discuss at the platform sprint): TODO12:35
apwany idea what it is about and what we ahould do with it12:35
ppisatiapw: it wasn't really an action12:36
ppisatiapw: i was looking for some useful configs for debugging12:36
ogra_apw, we discussed it last arm meeting, i thought i asked ppisati tzo close it12:37
ogra_(close as in POSTPONE to P)12:37
ogra_we will definitely have kernel config sync meertings at UDS for arm12:38
apwogra_, ppisati, thanks12:53
* ogasawara back in 2013:43
=== tgardner is now known as tgardner-afk
=== tgardner-afk is now known as tgardner
* apw is going to wander somewhere sunnier and enjoy the outside for a bit ... and think about quirks16:32
ckinghow quirky16:45
* tgardner -> lunch17:50
cr3hi 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?18:38
cr3is 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?19:52
dannfint main() {20:00
dannf  printf("long is %d bytes\n", sizeof(long));20:00
tgardnercr3, perhaps do some hackery with gcc ?20:00
tgardnerdannf, :)20:00
cr3dannf: 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 example20:02
cr3tgardner: 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:03
tgardnercr3, dpkg-architecture ? DEB_HOST_ARCH_BITS=6420:04
cr3dannf: 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:04
cr3tgardner: I like it!20:05
dannfcr3: 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 it20:05
tgardnercr3, requires dpkg-dev20:05
dannfdepends on what you're after of coures20:05
mdeslaurdoesn't sparc64 have 4-byte longs?20:06
mdeslauroh, maybe not20:06
cr3dannf: 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 udev20:07
cr3tgardner: I like less dpkg-dev but I'll certainly have a look at the source just in case it provides another hint20:08
cr3err, I like less *depending on* dpkg-dev... I do like dpkg-dev :)20:09
cr3rapture! /usr/share/dpkg/cputable20:11
* jjohansen -> lunch/run20:12
cr3that is one freaking useful table, x86_64 vs amd64 always annoyed me but this table makes for a meaningful conversion between the two20:13
tgardnercr3, glad we could help :)20:13
tgardnergotta go20:14
cr3tgardner: 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 hand20:14
pgranerogasawara, can you check into bug 71073320:51
ubot2Launchpad bug 710733 in linux "LKCD Not Executing kexec Properly" [High,Confirmed] https://launchpad.net/bugs/71073320:51
lamontin 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) ?20:55

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!