ADcomphello .. I can't run X with omapfb :/  some help ?  http://paste.ubuntu.com/355265/00:25
rcn-eeADcomp, i think omapfb requires running a dss2 enabled kernel: "Error opening /sys/devices/platform/omapfb/ctrl/name: No such file or directory" Although i've never run it on anything else either...00:28
ADcomphi rcn-ee .. I finally running karmic on my new board  :)00:30
ADcompbut I don't compile new kernel from your tree yet ..00:30
rcn-eehi ADcomp, i saw that.. (i was going to ask you about that too..)00:30
rcn-ee(i'd like to get all omap3 based boards working in that tree)00:31
ADcompI don't have a working OE setup for compiling kernel ..00:33
rcn-eeomapfb isn't really a driver per say, (doesn't interact with the SGX engine) it just enables some features... http://git.debian.org/?p=collab-maint/xf86-video-omapfb.git;a=tree;f=src;h=45b69d636f30e09cfdc817c95856297986dd8883;hb=HEAD00:33
ADcompbtw touchscreen doesn't work ..00:35
rcn-eeprobably isn't enabled in the defconfig, the original beagleboard doesn't have one..  might even have to patch for it..00:37
ADcompI don't think so .. It works fine with angstrom with same kernel00:37
rcn-eethere's a lot of kernels out there, (i just put two more out yesterday) which Angstrom works, and which one fails...00:39
ADcompI think it's related to HAL00:39
ADcomp(EE) ADS7846 Touchscreen Unable to query/initialize Synaptics hardware.00:39
ADcomp(EE) PreInit failed for input device "ADS7846 Touchscreen"00:39
rcn-eeADcomp, looking thru my tree's i've never enabled CONFIG_TOUCHSCREEN_ADS7846 which is what is needed..00:44
ADcompit's enabled in my config ..00:45
rcn-eesure, but that's why it doesn't work with my kernels or Angstrom's...00:46
rcn-eeif you build my 2.6-stable, add this to yesterday's patch http://pastebin.com/f1fe738b300:48
ADcompdo you think I can use this to setup OE and compil kernel ?  http://wiki.openembedded.net/index.php/Getting_started00:50
rcn-eethat's old, use http://www.angstrom-distribution.org/building-angstrom00:52
ADcompok .. ty.  what about MACHINE ?  beagleboard ?00:53
rcn-eebtw, that ADS7846 is a spi device, so arch/arm/mach-omap2/board-omap3"board".c will need to be patched.. spi devices need to be registerd...00:54
rcn-eenote sure... it's a beagle, but at the same time it's different.. all machines are listed in tree/conf/machine.... doesn't look like there is a tao...00:56
ADcompno .. but I can maybe ask to technexion for thunder.conf they use to build angstrom ?00:58
rcn-eeask them for an Angstrom (OE) overlay, a lot of companies are doing that now days. (specially for omap3 boards)00:59
ADcompbtw , this board is running fine under karmic .. X + Openbox   :)01:05
=== martinb is now known as Martyn
=== asac_ is now known as asac
loolHmm trying to run rootstock, I get mount -t devpts devpts /dev/pts11:13
loolmount: mount point /dev/pts does not exist11:14
ogralool, hmm, i thought there is a mkdir -p in the code11:46
loologra: I dont see any11:47
loolThis is in the installer BTW11:47
loolI tried moving udevd --daemon up one line, and get /bin/installer: line 14: udevd: command not found11:48
ograhmm, the mount should probably run after udevd starts11:48
loolI suspect ubuntu-minimal isn't pulled11:48
ograyeah, smells like11:48
ograsince you asked me to drop the hardcoding for it ;)11:48
loolIt says the default is ubuntu-minimal11:48
ograit should11:48
ograunless debootstrap has some out-of-sync'ness11:49
looldebootstrap will use priorities to select packages11:49
loolI'm trying with an explicit ubuntu-minimal now11:50
loolsame thing11:52
looludev was certainly downloaded11:53
loolI think it's broken for vms; not sure why11:55
loolsecond stage isn't set11:57
loolThe first failure is actually:11:59
lool+ echo chroot: cannot run command `debootstrap/debootstrap': No such file or directory11:59
loolrcn-ee: Thanks for testing the --script patch; I tested it myself now and fixed a couple of issues with it13:28
loolrcn-ee: Pushed a new branch and requested a new merge; http://paste.ubuntu.com/355487/ is the diff of the interesting changes, branch is lp:~lool/project-rootstock/user-script13:29
rcn-eethanks lool, just read the email actually..  ;)13:33
ogracooloney, they have to fix that14:01
ograthey were in the crowd shouting for v7, neon and thumb2 too :) so they should make sure to have their code working with a recent compiler :P14:02
cooloneyogra: yeah, understand14:02
ograasac, something for tonights call i guess14:02
asaccooloney: ericm_: you asked if we have cross compilers availble14:02
ograericm_, i thought lool prepared a ppa with cross tolls based on our compiler14:02
asaci dont know ... can you explain to me where you get those from?14:03
asaci thought you hvae to do them on your own14:03
cooloneyasac: yeah, cross compiler 4.414:03
ogralool, ^^^ is that gcc 4.4 ?14:03
ograasac, you use codesourcery14:03
cooloneyasac: normally, we get the binary gcc from codesourcery14:03
ograbut they are only on 4.3 iirc14:03
cooloneyasac: and i think the latest one is 4.314:03
cooloneyasac: but i am searching on their site now14:03
asacah. i thought you have to do that on your own ... is there a good wiki explaining what you do?14:03
ograamitk's blog :)14:04
loolI have cross compilers in my ppa14:04
loolThey are suitable for the kernel, but not for userspace due to a bug14:04
ograericm_, cooloney, ^^^14:04
ograso use these14:04
ericm_ogra, lool, thanks14:04
loolWe decided we wont go this way though, so I'm not investing in fixing these right now14:04
ericm_lool, you have a link?14:04
loolppa:lool/ppa ?14:04
ericm_lool, ok14:05
ogralool, as long as the kernel can be built ...14:05
cooloneyi think we can try this 4.4 cross compiler from codesourcery now14:05
loolFor the kernel, you might have to remove the libgcc linkage which I think should be dropped upstream; I think it's a terribly old construct14:05
loolYes, codesourcery has 4.4 now14:05
amitkI would be very conservative about updating to a new compiler14:06
amitkthey are almost always buggy14:06
cooloneyamitk: got you guys14:06
* ogra takes a break14:06
ericm_I think I've already been using the latest codesourcery gcc14:06
ericm_might be a good chance to give marvell toolchain a try14:07
persiaNative builds aren't that bad.  Try them!  You might find the results interesting, or even useful :)14:08
ericm_persia, ok - will try14:08
* ericm_ needs some sleep14:09
=== ericm_ is now known as ericm-Zzz
cooloneyericm-Zzz: good night14:11
asacdmart: hi14:40
* asac gets the thumb2 link14:40
asacdmart: so can we clearly prioritize by what type of issue we have?14:42
asace.g. swp > ldr > mov > ldrex (or some other order)14:43
dmartMaybe rather mov > (swp,ldrex) > ldr14:43
dmartI need to talk to the kernel guys, but we have a patch to emulate SWP in the kernel.  This is slow, but it avoids us having broken packages and gives us a chance to migrate14:44
dmartldrex packages may not be SMP-safe14:44
dmartldr packages my just "perform a bit better" if built in ARM14:45
dmart...so I separated them out and we can consider them low priority14:45
asacok i added a few columns to the table14:47
asacwhich we can later use to sort:14:47
asacrdepends (number of packages that depend on it)14:47
asacsection (base, standard, optional)14:47
asacand comments -> like for apex i added that its a none issue because its armv5 bootloader14:47
ograwe do use sections ?14:47
asacits good to identify if something is part of the base system etc.14:48
dmartI found a few packages in main which have no rdepends in main... it might be worth tracking thta14:48
asaclike binutils: is probably more important than some app14:48
asacdmart: those packages usually automatically get demoted . we have a component-mismatches14:49
ograbut i didnt know these sections actually mean anything in ubuntu14:49
asacogra: have that at hand?14:49
ograi thought they are debian only14:49
asacogra: they dont mean anything, but they give indication for the prioritization we are doing14:49
asacaka they still mean something, because they mean something in debian14:50
asacdmart: thx14:51
asacogra: thx14:51
dmartI don't mind :)14:51
asacdmart: that page above is regularly reviewed. stuff that has no rdepends in main should get demoted14:51
dmartOK, maybe we don't need to worry too much about that then14:51
asaclook for " Source and binary demotions to universe14:51
asacdmart: you said in your mail you wanted to do something ... and before that we shouldnt remove anything from that list. did that happen?14:52
asaci dont mind to keep everything in there14:52
dmartIf things get deleted, we don't track _why_ they were deleted... but we could move them to a separate table, with a brief note about why14:53
dmartThat was my only concern14:53
asacah ok. thats ok then. i think the comment column is good enough for now14:53
dmartI think the first job is to do a fairly quick review through the whole list, getting the info for your suggested colums, and quickly assessing the impact of the source code issues14:53
dmartMaybe it would be easiest just to chop the list for main into a few pieces and try that?  Do you know who would be available to review?14:54
asacright. so the mechanic stuff i can get someone doing (e.g. fill in the number of rdpends and then sort the wiki page14:54
dmartYep, that should be fairly straightforward and quick to do14:54
* ogra is happy to report that the imx51 kernel in the archive works well 14:55
dmartogra: Is that
ograyep, the one uploaded yesterday14:56
dmartAh... I have a board here running it too14:56
dmartseems OK14:56
asacdmart: do you think it would take longer than 1h or so if we go through the list together here to add tne initial comments? that would ensure we make the progress and we dont have to wait on someone ;)14:56
ograits aweesome14:56
dmartasac: No, that sounds like a good first step14:56
asacthen i will get someone filling the sorting columns and we can distribute the real porting tasks to individuals based on that14:56
ograway better than any first-release we ever had14:57
asacok lets get started then ;)14:57
asac#startmeeting ;)14:57
asacthats the first package in the table ;)14:57
dmartapex is first (though probably ignorable)14:58
asaclet me open the filtered lists14:58
asacdmart: yes, already filled in the comment ;)14:58
* dmart hits refresh14:58
dmartMight it be better to split the list and work offline?14:59
asacif that works for you. i just think its going to take longer that way ;)14:59
asacunless one takes all the workload14:59
asaclet me open the filtered files ... then i hope it will go quicker15:00
dmartAll binutils and gcc packages: I suggest to ignore. This is dealt with separately with doko etc.15:00
asaci can fill in the comments we find15:01
asacso we dont get conflicts15:02
asacdmart: eglibc too i guess?15:02
dmartActually, gcc-4.4 has a problem with swp in the boehm-gc code... I'll try and find the lp bug tracking this for openjdk15:02
dmartHmmm, no lp bug.  Can you add a note on that?15:03
asacadded that to comments15:05
dmartboost1.38 and boost1.40 both contain spinlocks and atomics code using swp15:07
asacok finally have all the filtered files15:07
asaccacao-source ->15:08
dmartHow to I find out the rdepends for a source package?15:08
dmartcacao-source has the same boehm-gc problem as in gcc-4.4, and also uses swp in a couple of other places.15:09
asacldrex seem to be used in armv6 header there15:09
asacdmart: hmm. you have to check rdpeends for the binaries15:09
dmartOh, OK15:09
asacone could write a script for that15:09
dmartI was hoping you had one :)15:09
asacor are you looking for build-rdepends?15:09
dmartNot really, should we?15:10
asacdmart: no. but i will get someone else fillin the rdepends ;)15:10
asacdmart: that would be useful if we have issues in inline funcs in headers15:10
asacbut i hope not ;)15:10
dmartDo you want to move this discussion to another channel?  This is a lot of spam for people who aren't interested15:11
asacdmart: i think its ok this channel quite quiet ... if you prefer we can go somewhere else15:11
persiaapt-cache rdepends ${package} can be useful15:11
dmartasac: OK, stay here for now them15:12
persiaBut one has to check the results, as it also lists Conflicts and Breaks, etc.15:12
asacdmart: unless someone complains ;)15:12
asacso cln15:12
dmartaptitude is also useful15:12
asacgrep cln * | pastebinit15:12
dmart... is a JIT and it likely to make a lot of assumptions about ARM versus Thumb-2... some real work is probably needed for this.  We should check with doko on priority for this one15:13
asacdmart: yes. i will add a comment about jit needing work15:14
dmartcln -> I already had a brief look.  This is some kind of arbitrary precision library. The seems to be some run-time compilation for ARM, but comments in debian/rules say it's broken and appear to disable it anyway.15:15
dmartI think there are no rdepends in main for this one?15:16
asaccheck apt-cache rdepends libcnl615:17
asacthere should be a bunch15:17
asacoh in main15:17
asacyes the lib is in binary demotions15:17
asacbut probably "pi" is used15:17
asachmm. just by the lib from what i can tell15:18
dmartYou can check this with a limit like ~smain~Dlibcln in aptitude15:18
asacdmart: so based on the grep those movs in cln needs to be fixed?15:18
dmartpi is a demo program which computes pi :)15:18
dmartIn debian/rules it says "CLN's assembler support is not working properly ..." and adds -DNO_ASM.  I did an offline build--- it builds in Thumb-2 without errors and the testsuite passes OK, so I think the assembler is not used.15:20
asacok. great.15:20
asacseems just one swp15:21
asacin a test15:21
* asac checks build log if make check is run15:22
dmartI think that's a false positive... doesn't look like assembler to em15:22
asacthat test passes15:23
asacPASS: misc/printf-cov15:23
asacon armel15:23
asacbut that was karmic15:23
asace.g. needs to get respun15:23
dmartI can't see any reason why printf would have atomics anyway15:23
asacok db15:24
asaci thinnk i fixed db4.215:24
asacat least i added gcc atomics there to fix a build failure15:24
asacand the newer db versions seem to use pthread mutexes15:25
asaclike db4.6 doesnt use that code anymore iirc15:25
dmartOK... db (4.8), db4.2 and db4.6 all seem to have the same code; can we apply the same patch to them all?15:25
asacdmart: yes, we probably can, but only 4.2 failed on that code, which is why i didnt do that15:26
asacanyway, we might want to do that anyway, and hope it flows upstream at some point15:26
dmartMight be a good idea.  Code involving swp will generally work (and pass tests) on our current platforms (except maybe on dove under stress?) ... this is more for avoiding future problems.15:27
asacsearch-arm-mov.filt: ./djvulibre-3.5.22/libdjvu/GThreads.cpp:                    "mov%?\t%|pc, %1"     // branch to address %115:27
asacdmart: hmm ... strange that it failed to build for db4.2 though15:27
asacanyway, lets continue15:27
asaci noted that we should put the patch everywhere15:28
dmartdb* - should we flag this up for SMP safety, or are you confident the memory barriers implied by the GCC intrinsics are adequate?15:28
asaclets flag this up. no clue if i messed it up ;)15:28
dmartOK, djvulibre15:29
asacseems that mov is assembler ...15:30
dmartLooks like it may need fixing. mov pc, <Rn> won't interwork correctly if built in Thumb.15:30
dmartIf it's in threading code, the branch could be supposed to go absolutely anywhere15:31
asacok ... dmake15:31
dmartdmake - looks like a false match: it's a sed munge in a Makefile15:32
dmartSH_n    = $(@:s/swp-/-/:s,-,/,:s/scripts/${SCRIPTFILE}/)15:32
asaci have eglibc currently in the same boat as gcc etc.15:32
asacif you disagree we can make that a doko tasks15:32
asacsearch-arm-mov.filt: ./emacs23-23.1+1/lisp/emulation/pc-select.el:     (pc-select-add-to-alist pc-select-saved-settings-alist ,var ,var)15:33
dmartIt might be a good idea to flag up all the toolchain type stuff for doko to give a judgement on15:33
asacemacs23 sems to be a false positive15:33
asacgrep erlang * | pastebinit15:33
dmartI guess so. I think elisp is strictly interpreted15:33
asac(emacs: the .el line is the only line that is in your filtered list, so its a false positive, yes.)15:34
dmarterlang: someone needs to take a more careful look.  There might be some runtime code gen in there15:35
dmartIt looks a bit like it from the matches15:35
asacyes, and the grep shows code that needs to be checked15:35
asacsearch-arm-mov.filt: ./espeak-1.41.01/platforms/riscos/s/assemb:MOVNEr8,pc15:36
asachmm. riscos?15:36
asacwould that be us?15:36
* asac wont think so15:36
ograubuntu-risc FTW !15:37
dmartUnlikely to apply to us.  Someone chould probably check it out... maybe some code was written for riscos but reused on ARM generally.  But it feels low priority15:37
dmart(last comment applies to espeak btw)15:37
asac ./evolution-data-server-2.28.1/libdb/dbinc/mutex.h:asm volatile("swpb %0, %1, [%2]"15:37
asacseems that might be atomics15:38
dmartLooks like it15:38
asacffmpeg -> guess that needs to build first ;)15:38
dmartFTBFS, or just not built yet?15:38
asacdmart: it currently ftbfs even15:39
asacbut chromium ffmpeg builds ;)15:40
dmartWe should check whether chromium ffmpeg is using the ARM asm and NEON in particular15:40
dmart... should there be a separate ffmpeg there at all though?15:41
asacwe dont use NEON, because we dont have NEON atm and the rest of chromium will not use hwcaps to use it based on support15:41
Martynnot surprised15:41
asacdmart: well. we kind of accepted that trying to use system libs for chromium isnt worth the effort15:41
asacthey usually pull in snapshots15:42
asacand bump the revisions pulled in frequently15:42
MartynI'm still trying to get NEON to work correctly in the latest builds of GCC15:42
dmartI'll try and raise a lp bug on that.  Eventually, we do want good video performance in a browser ;)15:42
asacMartyn: ffmpeg?15:42
MartynEven the latest CodeWarrior gcc doesn't seem to quite get it right15:42
asacdmart: there is a bug related ... one sec15:42
loolCodeWarrior or Sourcery?15:42
MartynHeh, spellcheck auto-fsked that15:43
asacdmart: ^^15:43
asacthats where i asked about it15:43
asacthough it was for non ffmpeg related neon15:43
Martynhowever, I have seen some hand-coded ASM libs that reference NEON15:43
asacguess ffmpeg could be done15:43
Martynand do the check to see if it's a vfp or NEON enabled processor15:44
dmartFor ffmpeg proper, we build a separate library flavour and use ld.so hwcaps15:44
Martyn(not ffmpeg.  In muy case, it's marble .. a biotech program)15:44
dmartThere's a lot of hand-optimised code in ffmpeg anyway, so it may make sense to built ffmpeg with -marm.  This might be done already, but can you make a note to double-check it?15:45
loolNot built with -marm ATM15:45
asacdmart: i saved what we have for now. i will probably finish and fill in what i can see after call15:46
Martynlool : Shouldn't we be building with -marm?15:46
asacffmpeg? thats the plan afaik15:46
dmartOK.  I guess ffmpeg needs a bit of further review, but it doesn't look like there's a major problem15:46
MartynOr is the effort to build v7-a thumb getting in the way of that?15:47
dmartMartyn: in the way of what?15:47
asacusing -marm15:47
dmartNo, we can still use -marm for specific packages15:47
dmart...if needed15:48
dmartIs this effectively a port of GCC? I was never too sure15:48
asac XML output extension to GCC15:48
asacno clue ;)15:48
dmartAnother one for doko then.  I suspect it's a non-issue15:49
asacok noted15:49
dmartgdb -> doko ?15:50
asacghostscript seems to be false positive15:50
asacgrep ghostscript  * | pastebinit15:51
asacsearch-arm-swp.filt: ./glib2.0-2.22.2/glib/gatomic.c:    "swp %0, %1, [%2]\n"15:51
asaci think thats fixed15:51
asacby using intrisincs if available15:51
asacbut i will add item to check that15:51
dmart I think I posted a patch for that :) I can probably get the bug number15:52
dmartglib2.0: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/49187215:53
ubot4Launchpad bug 491872 in glib2.0 "[armel] Atomic intrinsics are not implemented correctly" [High,Fix released]15:53
asacok ... taking quick break; then call!15:54
asacsaved the wiki15:54
dmartOK, thanks for the progress so far, I think that's 30-40% of the main list15:54
asachehe yeah. took some time to ramp up, but that should be quick. of course loads of porting work will come out of this - so we definitly need to prioritize reasonably15:55
asachmm i busted the wiki table ;)15:55
dmartDoing a quick first pass so we can make the right decisions seems the right thing to do15:56
asacfound the issue15:56
* asac checks if ffox 3.6 is happily spinning on arm before going away19:55
asacok seems like. waiting for xulrunner to finish: https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.319:56

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