=== rsalveti_ is now known as rsalveti === freeflyi1g is now known as freeflying === ericm-Zzz is now known as ericm|ubuntu === hrw|gone is now known as hrw [08:00] morning [08:00] Morning hrq [08:00] hrq* [08:00] Grrrrrrrrr [08:00] hrw* [08:00] :) [08:00] Stupid fancy keyboard! [08:01] ;D [09:07] lag: can you boot the .34 panda kernel which was built by yourself? [09:08] Yes [09:08] :) [09:08] I have been playing with it [09:09] lag: excellent, man, good to hear that [09:09] lag: thx [09:09] cooloney: No problem [09:10] Do you have HW yet? [09:10] too bad, no [09:10] i don't have omap3 and omap4 [09:10] Are you going to get HW soon? [09:11] igep v2 should be good omap3 testboard. compared to beagleboard (c4/xm) it is available [09:11] hrw: igep v2 is from TI or other vendor? [09:12] lag: no, i think there is no OMAP4 HW for me [09:12] lag: and for omap3, no idea about that [09:12] That sucks [09:12] other [09:12] lag: maybe i need to order some omap3 boards and ship to folks in US, and get the board during next sprint [09:13] cooloney: spanish company [09:13] hrw: ok, let me search [09:13] hrw: thx [09:13] I think I'd find it difficult working on an architecture without HW [09:14] cooloney: Do you know if a console is configured on HDMI on the Panda board? [09:15] lag: oh, not sure about that, let me check [09:15] cooloney: http://shop.igep.es/index.php?main_page=product_info&cPath=1&products_id=38&zenid=j4novjt0a4t4k1j0o2igoldhm6 [09:15] cooloney: we are trying to get some IGEPv2 boards for evalueation [09:15] cooloney: 130€ for no wifi/bt, 145€ for wifi/bt [09:16] they should work with our kernel, i've enabled it in the configs [09:16] hrw: nice, ehe [09:16] amitk: good to know that. hope i can get one of them to play with [09:18] yeah, hope so too === JamieBen1ett is now known as JamieBennett [09:27] lag: i am not sure about the HDMI console. so i believe you are using HDMI display with panda, [09:28] I want to [09:28] lag: can you see anything on it? [09:28] oh, you don't have [09:28] No, nothing [09:28] I do have [09:28] oh, how about change some kernel cmdline to add 'console=tty0' or similar [09:28] When I boot, I get 1,000's of these: omapdss DISPC error: SYNC_LOST_DIGIT [09:29] That was my follow-up question - Which console ... [09:30] ericm|ubuntu: I start merging your and mine patches now, OK? (You're not in #armlinux, so this is slightly off-topic) [09:30] I've been meaning to install a full desktop environment on my new SD card [09:30] I wonder how many working pandas are outside of TI [09:30] ukleinek, i'm ok [09:31] hrw: skip me, i don't have any [09:31] hrw: ehe [09:31] hrw: o/ [09:31] lag: hmmm, actually, i have no idea about that. [09:32] sebjan: do you not this console tty0 should be the right one for HDMI console? [09:32] sebjan: i think lag is trying to output our UNR on it [09:37] hrw: hi. not man panda outside of TI.. not many inside of TI anyways... [09:37] lag: which kernel are you using? [09:38] ndec: panda (the board) as endangered as panda (the animal) ? [09:38] 2.6.34-900-omap4 [09:38] Maverick [09:38] amitk: yep... we are trying to save the animal from disparation ;-) [09:39] ndec: yep [09:39] lag: do you have a HDMI screen or is it a DVI screen using the HDMI output of the board? [09:41] It's the real deal [09:41] HDMI->HDMI [09:42] lag: ok. well this should work without any config change, assuming you have the right config in the kernel... but i have not tried on HDMI screen yet. [09:43] Hmmm [09:45] ndec: On which console? [09:46] tty* [09:47] lag: don't know. i had tried HDMI->DVI screen several weeks ago with the UNE UI [09:47] I've just tested the monitor on my Revo running Karmic and it worked fine [09:48] The DVI port on the Panda has an HDMI socket, so I can't test that [09:50] lag: I am using the HDMI port (closest to USB). with the HDMI to DVI cable. I think we have problems with the DVI port. that one shouldn't work either... [09:53] ndec: No, that doesn't work as far as I can tell [09:53] But neither does the HDMI [09:54] ndec: Have you seen this message: omapdss DISPC error: SYNC_LOST_DIGIT [09:56] lag: yes... something wrong in DSS2/OMAP4 [09:57] i want one [09:57] Do you think it will be related to why I don't have HDMI? [10:00] ericm|ubuntu: do you want to look into my patches 4 to 9 and comment/ack? [10:00] ukleinek, OK [10:01] ericm|ubuntu: well, my 7 = your 2 [10:01] lag: yes. [10:05] ndec: can i get a panda? :D [10:06] armin76: why do you always ask me the same questions ;-) [10:06] last time it wasn't a question :P [10:06] armin76: good point... [10:06] armin76: let us know polish it first... [10:07] i want to polish it too :) [10:16] hrw wants to polish it too! [10:16] and zyga! [10:16] (zyga and hrw are in Poland) [10:17] Polish man meets English man and says: "I need to polish my English". English man replies: "No, your English is Polish enough". [10:17] joke sounds better then looks [10:22] hrw: nice... [10:22] http://alt-tab.org/data/images/2010/06/angelamerkel.png [10:38] lol :-) [10:52] anyone knows if it is possible to tell debuild to generate both a -dbg package a striped binary version? I know that I need to set DEB_BUILD_OPTIONS=noopt,nostrip for debug but this will provide me only the debug binary. I'd like to generate both in one command if possible [11:00] berco: Is this a package with -dbg packages in control? [11:00] berco: What you can do, and what Ubuntu does on all packages, is using pkg-create-dbgsym to achieve that [11:01] berco: You would build the package as usual, but the build will output -dbgsym packages along the other ones [11:01] lool: I have not changed the control file for this [11:01] berco: Just install the package and it should work (you might have to turn it on in /etc) [11:01] lool: I was looking more for the general rule to achieve this :) [11:02] lool: thanks. I will give it a try [11:03] * armin76 steals lool's panda [11:16] armin76: since when he has one? ;D [11:17] he stole it too :D [11:36] dyfet, how far are you with the gobject-introspection FTBFS ? === zyga is now known as zyga_away [14:16] npitre: ping [14:17] npitre: do you care to answer to http://mid.gmane.org/20100611045507.GA10894@pengutronix.de [14:17] ? [14:21] lool: ping [14:25] berco: pong [14:25] berco: Ideally, don't ping but just ask something so that I dont context switch twice ;-) [14:25] lool: thx for the dbg, seems to work. [14:25] Cool [14:26] lool: I now face another issue [14:26] lool: I noticed in my source package some files lost the execution privilege [14:26] lool: any idea how to prevent this? [14:27] berco: Sorry, what source is this? [14:27] lool: package that contains source code (apt-get source [14:27] berco: Yes, which one? [14:28] lool: well not public yet, it's for omap4, this is the "tiler" package [14:28] berco: Ok; would be easier to suggest a fix for a public source package [14:29] berco: So which file is losing the +x bit exactly and at which point? [14:29] lool: code has never been package. it's available but not in deb format yet. Am working on it... [14:29] berco: There are two places where that can happen: in your source files, because of the source packaging format, or in the resulting .debs [14:29] lool: this is bootstrap.sh file [14:29] berco: are you saying that the +x is lost when you unpack the source package, or in the resulting .debs? [14:30] lool: I need to check. I just did an "apt-get source" and noticed it's lost [14:30] berco: Right, so while unpacking the source [14:30] berco: So this is expected in the default source package format [14:31] berco: you could of course change the source format, but there's something odd here [14:31] berco: Usually, bootstrap.sh is part of the "upstream" tarball, the .orig.tar.gz [14:31] berco: Files in this tarball wouldn't lose this bit [14:31] berco: What might have happened here is that you intended to ship this file in the tarball, but it got shipped as part of the packaging instead [14:32] lool: ok, so I need to check b'cos this file should be in my .orig.tar.gz [14:32] berco: You really want this file to be in the upstream tarball I guess [14:32] berco: Please do [14:32] lool: thanks, that would make sense. I will check [14:32] berco: Also, might be best to just ask the chan rather than me specifically -- will get you faster answers, spread the load, and also I dont actually work on omap4 stuff (yet?) but others here do [14:33] lool: ok. Sorry I'm new to the Linux world so learning all the habits and stuff [14:35] berco: This is fine; I hope you don't mind me telling you [14:36] lool: not at all, just noticed you knew quite well the pcakaging topci [14:48] :q [14:58] when packaging from the .orig.tar.gz, I created a patch to move files but those that have +x attribute will lose it in the .deb source package. Anyone knows how that can be fixed. I want to keep the +x on these file. [15:00] btw, I'm using cdbs-edit-patch for creating the patch [15:02] berco: Why do you move the files? and why in a patch? [15:03] lool: git tree has the source code in a subfolder [15:03] lool: am not really allowed to change this and I created the orig.tar.gz with the simple "git archive" command [15:03] berco: You could either tell your package to build in a subfolder rather than build from the top, or you could release tarballs from the proper level? [15:04] lool: might be simpler in my case to build from the subfolder until the upstream maintainer modifies the git tree [15:04] berco: Without moving files in the git repo, could you strip a component when creating the tarball? [15:05] berco: Ok; if you're not upstream, then just go for the sub-folder build [15:05] berco: Set DEB_SRCDIR near the top of your rules if you're using cdbs [15:05] lool: yes, am using cdb [15:06] The default is ".", you could set it to subfolder or to $(CURDIR)/subfolder if you need an absolute pathname [15:06] lool: cdbs. I will try this, that sounds the most reasonable at this point === ericm|ubuntu is now known as ericm-Zzz [16:48] anybody formilliar with the sharp netwalker? [16:56] in-game: What's up? [16:57] in-game: persia might be the one to ask, but he's on holiday. [16:57] I believe he has one, though. [16:57] ahh ok [16:57] sweet device but the ubuntu running is 9.04 [16:57] yep. [16:58] so i am searching for a way to upgrade somehw [16:58] now running lxdm to make it some faster [16:58] in-game: unlikely you'll be able to upgrade [16:58] I don't think it supports 10.04. Iirc, it was a hardware issue. [16:58] the kernel hasn't been mainlined [16:59] thought so [16:59] pitty, the arm packages are some what lagging behind [17:00] in-game: it is mostly kernel and any binary drivers if reqd. [17:00] There were some hardware changes between 9.04 & 10.04. The newer kernels in 10.04 were never made to support the older hardware rev. [17:00] ukleinek: sorry [17:01] If you are kernel savvy, you could probably forward port the changes though. [17:01] in-game: the rest of the arm packages have been carried forward just fine [17:02] ok, yeah i wanted to update lxdm because of the network xplore function [17:03] Unfortunately 9.04 packages are built for ARMv5 and 10.04 were built for ARMv7. It would be like running x86_64 code on an Intel Pentium (P5). [17:04] in-game: you could enable the lucid repo in /etc/apt/sources.list and only upgrade certain packages [17:04] GrueMaster: the processor is a ARMv7 [17:04] amitk: The processor may be, but the kernel doesn't have support for it. [17:04] amitk tried that, but it deleted my x packages somehow [17:05] tried it twice now [17:06] GrueMaster: in-game does NOT want to upgrade the kernel, just the desktop. He can do that if the dependencies were carried over correctly [17:07] in-game: it is quite possible that the new version of the desktop brings in a new version of X which ofcourse doesn't have new version of some display driver or similar. That could kill your X [17:09] yups. [17:10] so hm first uprade the x [17:10] can add 10.04 to the repro and upgrade just without the kernel? [17:11] in-game: are you trying a 9.04->10.04 upgrade direct? [17:11] hmm [17:11] yeps [17:11] that is probably untested. Have you tried a 9.04->9.10 ? [17:11] maye first 9.10 [17:11] not yet [17:12] heh that is pretty good one :) [17:12] amitk: in-game: this is probably a bad idea. Netwalker kernel is very dated, and doesn't have proper thumb2 handling support which is required for lucid (you might get karmic to work) [17:13] NCommander: that is what I just suggested ^^ :) [17:13] yep :) [17:13] * NCommander brain farts, and goes to hide in a corner [17:15] no need for hiding, I tried it twice.... >< [17:16] hehe [17:21] Well lets try a update! [17:21] thanks for the info people [17:21] Speak to you later, if it works I will be back soon === hrw is now known as hrw|gone [20:52] Lucid isn't built with neon enabled by default, right? [20:54] neon in what? [20:54] libpixman includes neon routines for instance [20:54] but as far as I know, gcc never outputs neon instructions automatically [20:54] huh. that won't run on Dove then... [20:55] various packages include neon-optimized routines as alternatives but they're expected to work on non-neon systems too [20:55] I'll check, but I'd expect there to be guard clauses [20:55] exactly [20:55] ojn: its not [20:56] ok, thanks. [20:56] ojn: last time i checked ubntu had an old version of pixman which didn't had the neon routines [20:57] iirc pixman compiled automatically with neon, but it gets disabled/enabled at runtime [20:57] ssvb: is the master here :D [20:59] armin76, pixman-0.16.4 has some neon fastpaths [20:59] I'm looking at apt-get source libpixman-1-0 [21:00] doesn't have the more recent work done in january though [21:01] cwillu_at_work: as i said, ssvb should know for sure :) [21:01] armin76, argument screens off authority :p [21:01] iirc the neon stuff was reworked on >0.16 by ssvb itself :) [21:01] i.e., I'm looking at the source code :) [22:44] ojn, armin76, cwillu_at_work: lucid's and maverick's pixman have some NEON bits which are detected at runtime (via /proc/self/auxv) === bjf is now known as bjf[afk]