[08:16] Morning to the part of the world without bank holiday [08:16] Which part of the world *has* a bank holiday, and how do I apply? :) [08:17] RAOF, US and UK ant least. How you apply I don'T know. :) [08:17] My part of the world has its holiday Thursday [08:18] Ah. That might be why it's been unusually quiet. [08:18] Yep, time to get work done *cough, cough* [08:21] * smb waves to ikepanhc [08:22] hey smb & RAOF [08:22] smb: good morning [08:23] Hi jk- [08:25] * amitk waves [08:27] * cooloney waves back to amitk, smb, ikepanhc, jk- and RAOF [08:27] o/ [08:27] cooloney, \o [08:30] * ikepanhc waves [08:35] Can someone help me decide the importance of Bug #587136? [08:35] Launchpad bug 587136 in linux (Ubuntu) "2nd Resume from Suspend results in reboot on Toshiba Satellite U400. Fixed in 2.6.34 Mainline. (affects: 2) (dups: 1) (heat: 20)" [Undecided,Confirmed] https://launchpad.net/bugs/587136 [08:35] Based off the other linux bugs, I'm thinking High. [08:36] stenten, I would agree [08:37] smb: Thank you kindly. [09:35] smb: Hi Stefan, any chance to get the Lenovo x201 WWAN module into lbm? seems that mjg59 refactored it, according to the last mail [09:37] TeTeT, Its on the list to look at, now the other things have been done. I am not sure how far I get with all of it today and unfortunately I did not heve time to look at it again, yet [09:39] smb: the roll out for the customer is not before july 18th, so anything that lands for 10.04.1 is good enough. [09:40] smb: Should I escalate this driver support issue through Zaid, so it get's on your "official" todo list? or is it good enough as is? [09:42] TeTeT, Ok. Let me look at it to decide how much work it might be. I would ping you if I think it needs more work and thus a more official backing. [09:43] smb: thanks a lot, please let me know in any case [09:43] TeTeT, Sure [10:23] cooloney: hi, bryan~ [10:32] yzhao: welcome, yingying [10:32] * smb waves to yzhao [10:41] yzhao, yingying! [10:41] smb, do you know who's maintaining libusb? I wish I know where to send a relevant patch [10:42] ericm|ubuntu, Not from my head. Would need to ask checkmaintainer.pl too. Theoreticall Greg and Alsan Stern might be suspect. But I would see what the script says. [10:43] s/Alsan/Alan/ [10:44] smb, ah - not drivers/usb/, but a user space libusb library [10:44] it's in main repo, yet seems to be unmaintained by any of canonical member? [10:45] ericm|ubuntu, oh, user-space... eek. :-P [10:45] yet the bzr branch is progressing by , ..... [10:46] Maintainer: Ubuntu Developers [10:46] Original-Maintainer: Aurelien Jarno [10:47] ericm|ubuntu, So I'd post to both. The second probably is the debian maintainer [10:48] smb, how did you find this out? I executed dpkg-query -p libusb-0.1-4, only find Aurelien Jarno [10:48] but yeah, I guess these two mail addresses will work [10:49] apt-cache show libusb-1.0-0 (not on maverick, yet :-P) [10:50] Oh, wait libusb-0.1... ? [10:51] smb, yes - legacy and unfortunately upower seems to be linked with it [10:52] I guess I am just confused by one thing finding a libusb-1.0 and the other number being a 0.1 [10:53] ericm|ubuntu, But luckily the mail addresses are the same for both [10:53] smb, heh - since 0.1 is crap [10:54] that's why it's broken on my Mac [10:55] Heh, and somehow I got the impression both are produced by the same source package [10:56] ... no wrong... [10:56] ericm|ubuntu, So there is a libusb and a libusb-1.0 [10:57] smb, they are two separate [10:57] ericm|ubuntu, Which you probably were already saying by legacy lib linked agains upower === cooloney is now known as cooloney-afk === smb is now known as smb-afk [11:15] seems emerald.pgraner is down again === popey_ is now known as popey === smb-afk is now known as smb [12:30] Hi there, how do I find out what options are enabled in a standard Lucid kernel? [12:32] in /boot/config-$(uname -r) [12:32] diwic: 'less /boot/config-2.6.32-* [12:32] ' [12:32] heh [12:32] :) [12:33] thanks :-) [12:35] is there also an online list for different kernel versions than the one I have currently installed? === ghostcube_ is now known as ghostcube [13:51] Hello, [13:52] how can I cross- search for processor-chipset combinations in launchpad [14:08] hi [14:09] is it possible to crossbuild linux-libc-dev from linux source package? [14:36] hrw, I am not sure I understand what you mean with crossbuild. Build on another architecture? [14:36] smb: on amd64 build package with headers for armel [14:38] smb, do you mind have a look at my git pull request a bit time ago (just forwarded that mail to you)? [14:39] hrw, If you have the toolchain installed (though that is only available for i386 iirc) you could cross compile the whole package. Other I don't know [14:39] ok [14:39] hrw, ask in ubuntu-arm, they may possibly know [14:39] thx for info [14:39] mpoirier, Wouid you know something better? [14:39] ericm|ubuntu: will [14:39] hrw, not every package is cross-build-able [14:40] ericm|ubuntu, Ok, will do [14:40] smb, let me know if it needs a SRU process - it was actually sent before -L release maybe (or happened to be the freeze period maybe) [14:42] smb: what exactly do you want to know ? [14:42] ericm|ubuntu, Everything we now upload needs at least a little more process. Not yet looked into the mail, but one thing good to have would be a lp bug report that tracks/explains things [14:42] smb, LP bug report already there [14:42] mpoirier, It was about the cross complile question from hrw [14:42] and I've updated every commit with that info [14:42] ericm|ubuntu, Sounds good [14:43] smb, thanks man [14:44] mpoirier, I don't do many arm builds but the standard cross compiles of the whole kernel package. But I don't think there is a way to get the libc-dev package without a complete cross compile env. [14:45] smb: not that I know of... [14:46] mpoirier, Ok, thanks for the confirmation. [14:46] smb: the cross-compilation environment is changing for maverick - for ARM at least. [14:46] smb: for OMAP4 I should say. [14:47] mpoirier, Something I probably need to inform myself sooner or later [14:47] or saying educate myself [14:48] smb: I wouldn't rush too quicly on that one... [14:48] I think it is still maturing. [14:48] mpoirier: the cross-build enviroment changing? how? [14:48] Changing is probably not the word I should have used. [14:48] mpoirier, Oh, now worries, I am seldom rushing. :) [14:49] gos no worries [14:49] amitk: I am working on making 'cross-toolchain' source package possible [14:49] * smb cannot type today [14:49] I was referring to Bryan's sbuild stuff, which differs from what was being done in Lucid. [14:49] smb: "ARCH=arm make headers_install" does not require cross toolchain [14:49] mpoirier: ah [14:50] Mind you, I am still plowing through that one. [14:50] mpoirier: there are two different things (sbuild and cross) [14:50] *they [14:54] hrw, That can be true. I am just not sure the debian build environment we use allows to produce the lib package without going through the architecture specific parts which also does the kernel image. [14:54] But then, I cannot say I am an arm guy... [14:56] smb: s/arm/anyotherarch/ even [14:57] I recently hacked binutils packaging and built cross binutils for alpha/hppa/etc just to test does it work [14:58] OK, so I should say when I did compile I either completely cross compiled or used native builds. [15:17] correct me if I'm wrong but does not 'linux' source package has broken builddepends? [15:17] Build-Depends: dpkg (>= 1.13.19), debhelper (>= 5), gawk [15:18] kernel-wedge was required to let me start building, then it broke due to lack of libefl-dev... [15:18] libefl to build a kernel package? [15:19] Makefile:504: *** No libelf.h/libelf found, please install libelf-dev/elfutils-libelf-devel and glibc-dev[el]. Stop. [15:19] make[1]: Leaving directory `/home/hrw/devel/canonical/2010/05-cross-compilers/ubuntu/maverick/source/linux-2.6.34/debian/build/tools/tools/perf' [15:19] make: *** [install-tools] Błąd 2 [15:19] dpkg-buildpackage: błąd: fakeroot debian/rules binary zwrócił status błędu 2 [15:19] aah, libelf, _not_ libefl [15:20] argh typos [15:20] hrw: I am assuming you're cross compiling, what is your exact command? [15:20] dpkg-buildpackage -b -uc -us -aarmel [15:21] with proper 'export CROSS_COMPILE' before it [15:22] Hm, in my lucid tree (master) [15:22] Build-Depends: debhelper (>= 5), cpio, module-init-tools, kernel-wedge (>= 2.24ubuntu1), makedumpfile [amd64 i386 lpia], device-tree-compiler [powerpc], libelf-dev, binutils-dev, rsync [15:23] hrw: and what kernel are you trying to compile [15:24] amitk: linux (2.6.34-4.11) maverick; urgency=low [15:34] hrw: how soon does the build break? I've started one now, no problems [15:37] amitk: did not checked but took some time - kernel got built first [15:37] (building modules now) [15:38] hrw: in any case, it is a problem on your side since we've got work arm kernels built on buildds in the archive [15:38] *working [15:40] ok [15:40] amitk: sure, cross != native so problems can exists [15:40] and I am fine with it [15:41] hrw: we'll know soon enough, I'm building cross using your commands above [15:44] smb: https://wiki.ubuntu.com/StableReleaseUpdates === ghostcube is now known as babyrobbe === babyrobbe is now known as ghostcube === ghostcube is now known as sash_mobile === sash_mobile is now known as sash_mobil === sash_mobil is now known as ghostcube [16:33] hrw: confirmed the problem you are seeing with libelf with cross-compiling [16:38] mpoirier, https://edge.launchpad.net/ubuntu/+source/linux/2.6.34-5.12/+build/1762187 [16:39] https://edge.launchpad.net/ubuntu/+source/linux/+publishinghistory [17:06] smb: thanks for your quick answer, I'll see if we need to escalate this or can solve it with the customers repo [17:07] TeTeT, Ok, thanks. I think at least we should be aware of the implications beside the driver module [17:07] have a nice rest of day === hrw is now known as hrw|gone [17:08] smb: the customer has a blob from Lenovo for the firmware and they can use that internally. I'll talk to my Lenovo contact and see if there's a chance to ship it [17:09] TeTeT, I would also keep Pete informed as he kind of tracks the legal side [17:10] smb: no worries, if we pursue this, it's going through the proper escalation channels [17:11] Ok, cool === emma_ is now known as emma