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