#ubuntu-arm 2009-11-23
<lool> armin76: I did not
<zumbi> armin76: gentooish is ricing... i have not compiled it. http://code.google.com/p/chromium/wiki/LinuxChromiumArm
<armin76> zumbi: i know, and i tried that, but for some funny reason it wants to compile sse2 code, apart from needing a lot of ram
<armin76> so i guess nobody has compiled it :)
<saeedb> jerone_mobile:
<armin76> saeedb: *g*
<Martyn> Great UDS :)
<Martyn> It was nice to see some of you :)
<armin76> Martyn: thanks :)
<Martyn> So, loooooots of work to do
<Martyn> *rubs hands*
<JamieBennett> indeed
<ojn> Ok, got the serial port to my pegatron box. So are there any kernel patches for it (lange51) anywhere?
<ojn> Or maybe it'll run the babbage kernel just fine...
<ojn> interesting, redboot reports it as a babbage even:
<ojn> Platform: MX51 Babbage (Freescale i.MX51 based) PASS 2.0 [x32 DDR]
#ubuntu-arm 2009-11-24
 * ogra takes his first look at http://qa.ubuntuwire.org/ftbfs/ in lucid and boggles
<ogra> checking for C compiler default output file name...
<ogra> configure: error: in `/pulseaudio-0.9.20':
<ogra> configure: error: C compiler cannot create executables
<ogra> See `config.log' for more details.
<ogra> make: *** [config.status] Error 77
<ogra> root@dove:/pulseaudio-0.9.20#
<ogra> GRRR !
<amitk> ogra: do you have ccache installed?
<ogra> amitk, nope
<ogra> thats a lucid chroot under karmic
<amitk> ok, I see that error with dkms packages and ccache installed
<ogra> freshly set up, only instaled build-essential and devscripts in it
<zumbi> ogra: is it amd64 platform?
<ogra> thats on an arm platform indeed
<ogra> we dont cross build anything in ubuntu usually
<zumbi> uhm.. ok, i need to go now
<lool> ogra: and what does config.log say?
<ogra> nothing special apart from: configure: exit 77
<ogra> NCommander, so about pulse ... afaik the macros are for ARMv7 which is why i added that --march setting when we still were building for v5 , can you try to disable thumb instead ?
<ogra> generally they should work for v6 and v7 builds
<ogra> (they were added by the nokia community afaik, so should be for omap (i.e. v7))
<lool> ogra: Can you upload the full config.log?
<ogra> sure, one sec
 * ogra wonders how to convince chrome to not show that ugly blue when highlighting stuff
<ogra> lool, http://people.canonical.com/~ogra/config.log
<lool> cc1: internal compiler error: Illegal instruction
<ogra> yeah, just saw that too
<ogra> i guess i should upgrade my dove kernel first :)
<lool> Yeah that looks like a memory or stability issue -- Z0?
<lool> Hmm no Y0 for you*
<ogra> Y0 but -204 kernel
<lool> I mean you don't have Z0
<ogra> right
<suihkulokki> while at pulseaudio, can someone tell me howto add a compiler flag for one file in a automakish sourcetree properly
<ogra> but my kernel is outdated
<suihkulokki> 0.9.20-1 in debian did it wrong, so I it didn't work in 0.9.21-1 anymore
<lool> suihkulokki: Don't think you can override per .o; I guess you can create custom rules or use convenience libs?
<lool> Oh you can actually
<ogra> thats what my patch does in karmic :)
<lool> See 27.8
<ogra> make -C src libpulsecore_0.9.20_la-svolume_arm.lo CFLAGS+=-march=armv6
<lool> libfoo_a_CFLAGS
<ogra> ^^^ my karmic patch
<ogra> indeed yours is more elegant
<suihkulokki> how would libfoo_a_CFLAGS translate to the svolume_arm.o ?
<lool> suihkulokki: Depends what you're building
 * lool reads source
<lool> suihkulokki: libpulsecore_@PA_MAJORMINORMICRO@_la-pulsecore/svolume_arm.o I think
<lool> Not sure how / is handled though
<lool> For the example of:
<lool>      noinst_LIBRARIES = libfoo.a
<lool>      libfoo_a_SOURCES = foo.c foo.h
<lool> suihkulokki: Actually nevermind, I can't read; they basically recommend using convenience libs or noinst libs
<lool> I read it too quickly
<saeedb> jeron-mobile:
<lool> So what you want is noinst_LIBRARIES = libsvolume_arm.a and libsvolume_arm_SOURCE = pulsecore/svolume_arm.c + libsvolume_arm_CFLAGS = whatever
<lool> and libpulsecore_@PA_MAJORMINORMICRO@_la_LDADD = libsvolume_arm.a
<NCommander> ogra, I'm not quite sure how to turn off thumb
<ogra> --nothumb ? :)
<ogra> (gusessing, no idea if that exists :) )
<NCommander> ogra, I'll have to read the manpage ;.;
<NCommander> ogra, Dave Martin did however give quote a few flags in his talk. I might try some
<ogra> hmm, where is he ?
<ogra> i thought i saw him joining
<ogra> oh, that was on -meeting
<NCommander> ogra, dmart is here as well :-)
<dmart> Hi
<ogra> ah
<dmart> To turn off thumb, you should use -marm
<lool> Yeah
<ogra> ah, right ...
 * ogra now remembers it from the talk
<lool> Too bad it's not detailed in the man page, just listed
<NCommander> ogra, I think we should still have a bug on this. Having pulse use thumb probably is a good thing.
<dmart> Ah, yes, pulseaudio
<ogra> yes
<ogra> and upstream should know about it
<NCommander> dmart, yeah, the issue is that there's some handwritten instructions in it that go bust in thumb2 mode
<ogra> they did some effort to add v6/7 support
<NCommander> dmart, since it tries to use conditionals that aren't availble
<ogra> so will likely be intrested in thumb as well
<NCommander> addcs/subcs
<ogra> yeah, that v6/7 patch is quite ugly
<ogra> bt nobody upstream has a clue about arm
<ogra> so lennart just accepted it blindly
<NCommander> ogra, *shiver*
<NCommander> ogra, if -marm works, lets push that, and then I'll asign a bug to myself on portng to Thumb2 mode
<ogra> i talked to him at the maemo summit and he said he just takes what people give him... but given he has no clue and neither HW he wont test it at all
<ogra> as long as it doesnt break x86 at least
<ogra> NCommander, cool
<NCommander> ogra, I did some reading on thumb2 mode, but the documentation is a bit thick :-)
<armin76> NCommander: i'm here too *g*
<NCommander> hey armin76
<NCommander> armin76, how's your handwritten thumb2 ASM? :-)
<armin76> NCommander: i suggest using -marm as well
 * armin76 runs
<NCommander> armin76, ;-)
<armin76> NCommander: i 'fixed' the sigbus on firefox on sparc, you slacker :)
<NCommander> armin76, thats nice. Now fix upstart :-)
<NCommander> Its a bad thing when /init crashes
<NCommander> */sbin/init
<armin76> on sparc?
<ogra> why should init crash ?
<NCommander> ogra, it segfaults due to alignment issues on SPARC
 * ogra points to the channel name :P
 * NCommander points to armin76's last comment and leaves it at that
<armin76> ok, staying on topic...
 * NCommander should probably poke his Y1
<armin76> NCommander: i'll fix it if you fix me not having an armv7 board :)
<NCommander> armin76, you can buy imx51 hardware now :-P
<armin76> NCommander: i get no profit from this, you do? :)
<NCommander> armin76, or buy a motorola droid and find a way to get root on it ;-)
<ogra> yeah, just win the lottery and buy a babbage board :)
<armin76> NCommander: can't i get your z0? :(
<ogra> its *only* $750 :)
<NCommander> armin76, I never had a Z0
<NCommander> armin76, I have a Y0, and a y1 (which is having issues)
<armin76> NCommander: can i get ogra's z0?
<NCommander> armin76, I think you should ask ogra instead of me :-)
<armin76> NCommander: but you can steal from him :)
<dmart> Oops... got distracted there
<NCommander> armin76, I'm not flying to Germany to break into his house, hide from his dog, steal his Z0, and fly back in the cover of night
<armin76> boo
<ogra> armin76, you can get all Z0's i have atm ...
<dmart> I took a look at the pulseaudio issue at the end of last week... there's an explicit CFLAGS+=-march=armv6 in debian/rules.  This is actually an architecture downgrade and turns off thumb2, when building for v7
<NCommander> hrm
<armin76> ogra: gimme!
<ogra> armin76, dont have any :P
<armin76> who has? :)
<NCommander> dmart, it should turn off thumb2, but it looked like it didn't actually turn off thumb2
<NCommander> armin76, lool and plars
<ogra> dmart, it was an upgrade (i added it when we still built for v5)
<dmart> NCommander: how do you mean?
<ogra> dmart, it needs to be dropped now
<ogra> in later karmic it was actually a no-op
<dmart> ogra: yes, I see
<ogra> in early karmic it fixed the same code thumb chokes on now
<dmart> Does anyone know a list I can subscribe to to get a record of all the build failures...?  doko told me at UDS, but I failed to make a note of it.
<ogra> which is hardcoded oma assemble stuff iirc
<NCommander> dmart, it looked like to me it was trying to do thumb2 with armv6 instructions
<ogra> *omap
<ogra> *assembler
 * ogra needs a typing course
<NCommander> dmart, http://qa.ubuntuwire.com/ftbfs/
<dmart> NCommander: did you need an explicit -Wa,-mimplicit-it=thumb to get it working?  I think my toolchain may be a bit out of sync, but I needed that
<NCommander> dmart, I'm still waiting for my lucid chroot to build
<ogra> NCommander, hmm ?
<NCommander> ogra, ?
<ogra> how did you do the testbuild that made you say it fails on thumb ?
<ogra> without having a lucid chroot
<dmart> OK; doko was going to make gcc pass -Wa,-mimplicit-it=thumb to as by default, but this was a recent suggestion and I don't know if it's merged yet.
<NCommander> ogra, I used a PPA during UDS
<ogra> a *lucid* PPA ???
<ogra> where did you get that ?
<NCommander> ogra, some of us have native PPAs ;-)
<dmart> Oh, right-- I used the "proper" lucid toolchain :P
<ogra> yeah
<dmart> Where should I be looking?  doko's PPA?
<NCommander> dmart, for lucid toolchains?
<dmart> re http://qa.ubuntuwire.com/ftbfs/, is there also a list I can subscribe to?   It might be easier to review failures as they occur.
<ogra> i dont think there is a list
<ogra> the uploader is the only person getting build failure notifications atm
<dmart> doko pointer at ubuntu-buildd-admins or something like that, but I don't see that on lists.ubuntu.com
<armin76> lool: gimme your z0!
<dmart> NCommander: lucid toolchains, yes
<NCommander> dmart, well ... I think the answer is run lucid on ARM? :-)
<dmart> NCommander: that's what I was doing :)
<NCommander> dmart, then you should already have the right toolchain
<ogra> that should be fine
<dmart> NCommander: OK, I'll update and retry.
<dmart> NCommander: have we also tried -marm for the problem file, instead of letting it default to Thumb-2?  Because the hand-written code may have been manually optimised for ARM, this may give better performance than Thumb-2.
<NCommander> dmart, per-file CFLAGS scare me.
<dmart> In general, yes; but debian/rules already has that in this case.  Just a suggestion--- alternatively it might be a good idea to add a comment or raise a flag somehow reminding anyone maintaining the code later that porting to native Thumb-2 would be a good idea
<dmart> btw comparing .text sections, the overall code size does seem to reduce by just under 30%
<dmart> ...not a very comprehensive test, but it doesn't contradict our expectations.
<NCommander> dmart, its a different file that makes things go bust
<NCommander> dmart, is there a handy ARM to Thumb2 guide?
<NCommander> dmart, I think the CS conditional code isn't being allowed in the block, but I'm not sure how I'm supposed to work around that
<NCommander> ogra, actually, I found documentation on how to properly Thumb2-ize this code
<NCommander> I'm going to try fixing it properly first, and then testing
<NCommander> Martyn, how's your thumb2 looking these days :-)?
 * Martyn looks at one hand, then the other..
<Martyn> Looks like I have both thumbs...
<Martyn> *silly grin*
<Martyn> good, although we really need to verify that thumb2 vs/ full ARM really /does/ save code space
 * NCommander whacks Martyn with an ARM reference manual
 * Martyn drops the ARM TRM for Cortex A9 on NCommander
<NCommander> Martyn, I just want a second set of eyes to make sure I'm not using IT correctly
<NCommander> ACK
 * NCommander throws an execution error as I'm not TRM compatible (yet) :-)
<NCommander> Martyn, er, using IT correctly
 * NCommander has never had to use it
<NCommander> and ...
<Martyn> NCommander: Make sure you have thumb2 support compiled into your kernel flava of choice
<NCommander> ugh
<NCommander> pulseaudio just uninstalled itself on dove
<NCommander> \o/
<Martyn> WIN
<NCommander> Martyn, so if I have an addcs, and movcs instructions
<NCommander> I can do this:
<NCommander> ITT CS
<NCommander> ADDCS r0, %1
<NCommander> movcs r6, 0
<NCommander> to make the linker shutup about CS being in an IT block
<NCommander> Since IT takes CS as the condition, and then additional T to tell it that movcs should also be run as true
<Martyn> sure, but that's solving the problem by using a large brick, tied around a cricket bat, and shoved into the problem with a 10 foot ram
<NCommander> Martyn, huh?
<Martyn> it solves the symptom.. but I'm more curious why that code would get generated in the first place
<NCommander> Martyn, oh, this is handwritten ASM
<NCommander> Martyn, not auto-generated
<Martyn> Ah, in which case you've given yourself all the rope in the world :)
<NCommander> Martyn, this is pulseaudios codebase :-P
<Martyn> oh.  ugh
<NCommander> I've never needed to use IT before because i've never coded in Thumb before
<NCommander> I just wanted a sanity check to make sure I'm reading the reference page right
<Martyn> you are
<NCommander> Martyn, thanks
<NCommander> Martyn, ARM's reference manuals freaking rock
<Martyn> Want something that rocks harder?
 * NCommander is considering buying a dead-tree version for handy desk reference
<Martyn> http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001l/QRC0001_UAL.pdf
<Martyn> THAT is what is printed next to my desk
<NCommander> Martyn, OOOH, an updated version!
<ogra> NCommander, you should probably take a look at what angstrom does btw
<NCommander> Martyn, (I have the older one with ARM)
<Martyn> Yep
<ogra> i can imagine they already have proper fixes
<NCommander> ogra, for pulse?
<ogra> yes
<NCommander> ogra, I didn't realize they used thumb2 compiling
<ogra> i thnk they use every optimization omap can do
<NCommander> 1 angstrom = 1.0 Ã 10-10 meters - that google search was useful :-P
<ogra> search for "angstrom beagle"
<ogra> or ask in #beagle
<dmart> NCommander: dmart, I think the CS conditional code isn't being allowed in the block, but I'm not sure how I'm supposed to work around that: Building with v7+thumb2, you're effectively telling the assembler to pretend that that (ARM) inline assembler is unified assembler source (this is the new syntax that can be assembler to ARM and Thumb)
<dmart> ...however, it is actually the old ARM syntax, to it doesn't contains the IT block annotations needed for Thumb-2
<dmart> gcc -Wa,-mimplicit-it=thumb asks the assembler to guess what the IT blocks should have been instead of barfing
<dmart> This option should be in the toolchain by default; but I'm not sure if it's merged yet; that was my earlier query.
<NCommander> dmart, I rather just specify it properly */2 cents*
<dmart> NCommander: specifying it properly is preferable, but you will need #ifdefs to allow the result to assmble when compiled as ARM (e.g., for the Debian folks)
<dmart> Migrating over time would be good, but there might be a lot of bits of assembler to port if we try to do it all up front.
<dmart> The -mimplicit-it=thumb thing is used for Thumb-2 kernel builds, for example.
<NCommander> dmart, doesn't the assembler known what the IT instruction is?
<NCommander> (I can put #ifdef (__thumb__) or whatever the correct ifdef is
<dmart> NCommander: for historical reasons, GCC uses the traditional assembler syntax when compiling for ARM, and as does not understand IT blocks in this mode (unfortunately).
<NCommander> dmart, so ifdef's it is :-/
<ogra> on a sidenote using -marm works ... so we have a fallback if you dont manage
 * ogra just has it building
<NCommander> ogra, thanks. I'm just dist-upgrading karmic to lucid so I can test the resulting binaries after I finish building
<dmart> NCommander: Absolutely--- -marm is our friend if it looks like we're wasting time on any particular package... we can fix problem cases later.
<ogra> NCommander, given that pulse seems to block the livefses we should probably go with it as a quick fix so we have images asap
<NCommander> ogra, just give me a few hours to see if we can fix it properly.
<dmart> NCommander: feel free to throw me your code if you want me to sanity-check.
<ogra> yup
<NCommander> dmart, I'll take you up on that offer
<ogra> NCommander, just if you dont mamange it before your holiday
<NCommander> ogra, right, of course.
<NCommander> ogra, we probably should have a wiki page with problem packages
<ogra> NCommander, we have the ftbfs list
<ogra> and if you add a workaround you should simply keep it in mind
<ogra> and indeed note it in the changelog
<NCommander> ogra, fair enough
<dmart> Can anyone suggest a wiki page to track how we fixed packages.  We don't have to track everything, but it would serve as a FAQ for anyone faced with this task.
 * NCommander isn't looking forward to getting OOo building with Thumb2
<ogra> i guess the angstrom ppl solved that already
<ogra> dmart, i dont think we have one yet
<NCommander> ogra, angstorm isn't built for Thumb2 according to #beagle
<ogra> dmart, so feel free to create one in the /ARM namespace on te wiki
<ogra> ok
<NCommander> food time
<dmart> OK... I'll create an empty page and we can stick stuff on there
<ogra> oki
<dmart> NCommander: gcc defines a macro __thumb2__ which is probably what you want to check for in #ifdefs (maybe you could define a helper #ifdef __thumb2__ // #define THUMB2_ONLY(string) string // #else // #define THUMB2_ONLY(string) // #endif
<NCommander> dmart, with implicate-it though, aren't we masking the problem versus properly fixing it?
<NCommander> ^- ogra, asac
<ogra> NCommander, see -devel backlog
<ogra> adding IT is surely the best but likely produces a lot of work
<NCommander> ogra, *grumble*
<ogra> NCommander, implicate-it is similar but needs to be done on a per file basis
<NCommander> ogra, per-file basis? I thought you said the default was going to be changed to implicate-it
<ogra> which in case of pulse is moot because we already do it for that specific file
<ogra> right "going to be"
<NCommander> That's the issue I have.
 * ogra just wants a livefs to check the images
<NCommander> I rather have the issues be flushed out
<NCommander> And then add it on a per-package basis after bugging upstreams
<NCommander> ^- asac - your opinion?
<ogra> god ... the debhelper stuff in pulse takes nearly as long as the whole build
 * NCommander hands ogra a bottle of bleach for his eyes
<ogra> heh
<ogra> seems also that every module has an initscript nowadays
<NCommander> ogra, my only issue with implicant-its, which will work, is we're plastering over an issue over properly fixing it. I have no objections on specifying it on a per package basis, as long as we keep note of those packages
<NCommander> oh wow
<NCommander> GCC ICE'ed on lucid here
<ogra> well, go ahead and fix the code but i doubt you can do it as quick as just switching the hack we already have
<ogra> i'd really like to have testable images by end of the week or even earlier
<NCommander> "cc1: internal compiler error: Illegal instruction"
<NCommander> Uh oh
<armin76> ricer
<ogra> NCommander, yes, i uploaded my config.log with the same error about 3h ago
<ogra> NCommander, though i thought its caused by using the -204 dove kernel ... intresting that it shows up on a recent one too
<NCommander> ogra, lucid on dove doesn't even get to start X
<ogra> NCommander, it works flawless on the babbage
<NCommander> It dumped me to the console
<NCommander> CONFIG_ARM_THUMB is set in config
<ogra> THUMB or THUMB2 ?
<NCommander> THUMB2 isn't even in the config file at all
<ogra> i doubt it has anything to do with kernel options though
<NCommander> ogra, I'm getting a sinking feeling ATM.
<ogra> like ... having to do more work on dove than expected ? :)
<NCommander> ogra, like, are we sure dove supports Thumb2 properly?
<ogra> well, marvell said so
<NCommander> and are we compiling for Thumb2 properly :-)?
<NCommander> dmart, ping?
<ogra> you should ping marvell :)
<NCommander> dmart, do we need special kernel foo for Thumb2
<NCommander> ogra, I just want to make sure we don't need a special CONFIG_* something in the kernel
 * ogra doesnt think so ... only if you want the kernel binary itself to be thumb2 as i undrestood
<NCommander> ogra, context switches and friends would have to be thumb2 aware though
<ogra> root@babbage2:/pulseaudio-0.9.20# ls -l ../pulseaudio_0.9.20-0ubuntu2_armel.deb
<ogra> -rw-r--r-- 1 root root 1081438 Nov 24 16:31 ../pulseaudio_0.9.20-0ubuntu2_armel.deb
<ogra> there we go
<ogra> ogra@babbage2:~$ grep -i thumb /boot/config-2.6.31-105-imx51
<ogra> CONFIG_ARM_THUMB=y
<ogra> # CONFIG_ARM_THUMBEE is not set
 * NCommander takes his proposed patch and pops it into a PPA
<ogra> so as you can see, babbage doesnt have it set either
<ogra> THUMB is there but no THUMB2
<ogra> the pulse build is done in a lucid chroot on a karmic install ...
<NCommander> ogra, this is a pure lucid system here
<NCommander> things are quite broken
<ogra> well, we use jaunty on the buildds
<ogra> with lucid chroots
<NCommander> ogra, ugh
<NCommander> ogra, I think there's an alignment fault in X
<armin76> :D
<NCommander> cat alignment says User: 9, and Skipped: (
<NCommander> *9
<NCommander> when I startx
<NCommander> that goes to 10 and 10
<ogra> well, works on the babbage
<NCommander> ogra, whats /proc/cpu/alignment say?
<ogra> whatever we defaulted to in karmic
<NCommander> ogra, I'm curious if its skipping the alignment faults or not
 * ogra tries pulse with -mimplicit-it=thumb
<ogra> -marm definately worked
 * NCommander has a patch that adds the itt line but can't test it
<ogra> NCommander, i'll care for X stuff once i have images ... i wont trash my test-build systems
<NCommander> rabeeh, ping?
<NCommander> ogra, I think we set the default /proc/cpu/alignment to 2 (fixup) so alignment faults won't break the world
<NCommander> ogra, for some reason, thumb2 seems to break alignment fixup on Dove
<zumbi> ogra: did you solve configure: error: C compiler cannot create executables ?
<ogra> NCommander, -Wa,-mimplicit-it=thumb works too ...
<NCommander> zumbi, no, but I can reproduce it
<ogra> zumbi, nope, i just use a board thats known to work :)
<NCommander> zumbi, cc1 is abending with alignement exception, and illegal instruction
<ogra> since i want to get the stuff done
<ogra> the CC error is definately hardware bound
 * NCommander can't get anything done now on lucid due to this bug
<NCommander> argh
<ogra> it wont work with karmic either
<zumbi> when building cross compilers on amd64, I get similar errors, since today at my localhost it used to work, while at my remote host I got that error. I think there is something wrong on binutils
<NCommander> ogra, which binutils you got installed?
<NCommander> bbiab
<ogra> NCommander, i can tell you in ~1h when pulse is done
<ogra> the one thats default in lucid
<ogra> as i said, its a lucid chroot
<NCommander> ogra, right, fully up-to-date then?
 * NCommander just wants to make sure
<ogra> NCommander, debootstrapped right before building, so yes
<ogra> unless doko uploaded something i missed within the last hour
<ojn> NCommander/ogra: Once you're done doing the feasibility tests, I recommend giving the thumb2 userspace (and kernel) a good workout on babbage. Cortex-A8 has some bugs that your toolchain _has_ workarounds for (if enabled), but they're not 100% fool-proof.
<ojn> Dove doesn't have them, since it's a separate implementation
<ogra> ah, that might be the cause for NCommanders probs then
<NCommander> ojn, ogra Dove isn't Cortex A8
<NCommander> It's Marvell ARMADA
<ojn> NCommander: right, which is what I said above
<ojn> Babbage is
<ogra> right
<ojn> I was going to bring it up at UDS but I saw there were patches in the toolchain for it, and figured it was worth to try it first. :)
<ogra> we'll escalate it to marvell
<ogra> and talk to our toolchain maintainer
<ogra> thanks for the heads up
<zumbi> NCommander: if you have some time, maybe could test with an older binutils (one from before august/september)
<Martyn> What is the name of the Canonical/Ubuntu service that monitors your servers for you?
<Martyn> It's driving me mad that I can't remembe rit
<ogra> landscape
<dmart> all: gcc can be made to pass -mimplicit-it=thumb to the assembler, as a permanent default.
<dmart> For inline assembler, the effect may be slightly non-optimal code
<dmart> For all other code, there will be no effect, so it's safe to have it as default.
<ogra> yeah
<ogra> and i just confirmed pulse is fine with -mimplicit-it=thumb ....
<ogra> it just finishes rolling the package in my testbuild
<dmart> Ideally, we would port everything to Thumb2, but I think that may be laborious and not so worthwhile.  Unless we actually reschedule and re-optimise the code, doing it by hand won't be significantly better than the implicit-it approximation anyway.
<NCommander> dmart, ogra, so for thumb2 on dove, the issue is at least partially alignment related. Setting alignment to nothing or warn causes a hang. Setting it to fixup causes an ABEND, and illegal instruction
<ogra> so if NCommander doesnt come up with a patch for the assembler code by tomorrow morning, i'll just upload that quick fix and drop it once the toochain uses it
<ogra> so we get a working pulse package
<NCommander> ogra, I'm testing my fix in a PPA ATM since my board useless to compile stuff on
<dmart> NCommander: Going back to your kernel question, the "Thumb userspace binaries" option (CONFIG_THUMB) is all you need to enable Thumb-2 support in the kernel.
<NCommander> dmart, bugger :-/
<ogra> ah, wasnt there a THUMB2 option as well ?
<ojn> THUMBEE?
<ogra> (though i dont see one i thought that was mentioned in one of the session notes)
<dmart> There is no separate "THUMB2" option because actually no extra support is needed in the kernel at all.
<ojn> ah, nevermind.
<ogra> great ... we're fine then
<ogra> CONFIG_THUMB is enabled in all our kernels already
<dmart> THUMBEE is something different; turn this on, since it's useful for JITs etc.; I know there's some openjdk work looking at this.
 * jhobbs pokes Martyn 
<dmart> I don't think any kernel config change is needed
<NCommander> dmart, do you know anything about thumb2 and alignment issues?
<dmart> My lucid chroot seems to work OK
<NCommander> dmart, what hardware?
<ogra> dmart, do you have a dove board around ?
<ogra> seems it has issues
<ogra> though i dont think its necessarily thumb related at all
<NCommander> ogra, just for the record, are you using a Y0 or Y1?
<ogra> Y0
<NCommander> Same
 * NCommander tries his Y1
<dmart> NCommander: i.MX51
<ogra> and i had the issue with a lucid chroot on karmic
<ogra> while you had the same with a plain lucid install
<NCommander> ogra, why do you think its isn't Thumb specific?
<ogra> why do you think it is ?
<ogra> its just a compile ICE, it can be caused by anything
<ogra> *compiler
<NCommander> ogra, no, the binary is throwing illegal instruction
<NCommander> Same as X
<ogra> especially i dont think the configure script of pulse checks anything related to thumb
<NCommander> ogra, Try building hello world
<NCommander> It goes boom.
<dmart> Apparently, alignment faulting is not enabled by default in the kernel on v6 and above, so I'm wondering why fixups are needed?
<ogra> right, and why does that point to thumb in your opinion ?
<Martyn> jhobbs : What?  I was on a call n stuff
<NCommander> ogra, lets see here, We moved to Thumb2. Suddenly alignment always says Skipped: on Dove, Xorg and gcc are failing with Illegal instructions
<ogra> it points surely to the toolchain, but i dont see any specific pointer to thumb
<NCommander> And I have Alignement trap: not handling instruction in dmesg
<ogra> NCommander, we also moved to armv7
<NCommander> ogra, fair enough.
<NCommander> ogra, at least its an easily reproduce test case :-)
<ogra> NCommander, and see ojn's comment above
<NCommander> ogra, about Cortex-A8 quarks? I saw
<ogra> yes
<NCommander> Its irreveleant unless the workaround causes issues in non-Cortex A8 chips
<dmart> NCommander: can you cat /proc/cpu/alignment
<NCommander> dmart, 2 (fixup)
<ogra> well, we use -march=cortex-a8, no ?
<NCommander> dmart, if its set to not fix it, then the app just hangs
<NCommander> dmart, User: 8/Skipped: 8
<ogra> and dove isnt 100% cortex-a8
<NCommander> Starting X or running GCC causes that count to go up
<NCommander> ogra, Dove isn't Cortex A8 at all
<dmart> All v6 processors and above support full unaligned access by default, excluding certain instructions.  Alignment faulting is optional
<ogra> NCommander, right, thats what i mean ...
<dmart> NCommander: what happend if you change /proc/cpu/alingment to 1 (warn) ?
<NCommander> ogra, (ah, English translation error :-))
<NCommander> dmart, apps just hang
<ogra> NCommander, which is why i think its rather an issue with the arch than with thumb
<ogra> s/arch/arch setting/
<dmart> Can you do an unaligned access from ARM and see what happens?
<NCommander> dmart, uh ...
 * NCommander has nothing handy
<NCommander> dmart, got some test code for me?
<dmart> How about
<dmart> void main(void) { unsigned long long dword = 0x123456789ABCDEF0; unsigned long result; asm ( "ldr %0, [%1, #3]" : "=r" (result) : "r" (&dword) ); printf("result = %lX\n", result); }
<dmart> I will try this now... I think it should print result = 3456789A, without falling over
<NCommander> dmart, hrm ...
<NCommander> dmart, bit hard to compile it when the compiler is falling over :-)
<ogra> build it on karmic and run it in your chroot ?
<ogra> err ...
<ogra> hrm, you upgraded the whole thing ... nm
<NCommander> dmart, ARM compiled it works
<NCommander> dmart, (User faults: 2 (fixup))
<NCommander> dmart, this is with an arm cross-compiler
<dmart> Hmmm, I can send you a couple of binaries?  What's the best way to do that?
<NCommander> dmart, email probably
<NCommander> dmart, the same binary compiled with -mtumb -march=cortex-a8 works as well on Dove
<dmart> Hang on a mo
 * ogra thinks we need a doko here ....
<NCommander> dmart, both work on all alignment settings and don't trip an alignment fault
<dmart> That's what I was seeing on i.MX51... Weird...
<dmart> I have to diasppear soon, but can you try triggering a signal when the problem happens and catch it in gdb?  It would be interesting to see what the problem code is.
<NCommander> dmart, I'll see what I can do
<dmart> echo 4 >/proc/cpu/alignment enables a signal on alignment fault; though if you're getting SIGILL anyway, you might not need that
<NCommander> dmart, yeah, that changes SIGILL to SIGBUS
<NCommander> dmart, I need to install ddebs so I can give you decent gdb output
<saeedb> NCommander: I didn't follow all the conversation, bug please note the armv6/7 cpus can handle unaligned access when bit 22 of the cp15 control register is set
<saeedb> bug->but
<NCommander> saeedb, right, but we're seeing an unusual issue on Dove Yx boards which shows up as an alignment trap
<dmart> Is the kernel config the same between these two kernels for CONFIG_ALIGNMENT (or CONFIG_ALIGNMENT_TRAP or whatever the name is)
<NCommander> dmart, its CONFIG_ALIGNMENT_TRAP=y on Dovce
<NCommander> *dove
<dmart> Same on imx51
<dmart> saeedb: You're right, but the control register U bit is legacy only: the armv7 architecture specifies that this bit always reads as one and you can't change it
<saeedb> I see
<saeedb> NCommander: what is the issue that causes alignment trap? is it thumb specific?
<NCommander> saeedb, we're not sure
<NCommander> saeedb, karmic to lucid moved the toolchain and compiled binaries to ARMv7+Thumb from ARMv6
<NCommander> er, Thumb2
<NCommander> saeedb, so it could either be Thumb2 causing the breakage, or something in the ARMv7 instruction set
<NCommander> saeedb, as far as I can tell, only X and GCC currently go boom
<NCommander> As I can boot the resulting system
<NCommander> and xsplash seems to semi-work
<NCommander> so I'm unsure
<dmart> The ARMv7 instruction set doesn't contain much different from v6, for general purpose code, so Thumb-2 seems more likely.
<dmart> I haven't tried to boot lucid yet; I've only been running a chroot.
<dmart> I have to disappear now, but if you send gdb output I'll take a look.  If it's possible to send me a coredump, that would be useful to look at.
<NCommander> dmart, lucid does boot
<dmart> NCommander: glad to hear it :)
<dmart> Catch you tomorrow
<saeedb> Ncommander:  can you add some debug code in the do_aligment fucntion and check what is the instruction mode?
<NCommander> saeedb, I checked the preprocessor flag is set for thumb2 properly, but I'm not sure how to check the register flags to see if we're in thumb2 off the top of my head
<rcn-ee> home for lunch and catching up on the irc backlog.  Just to let you know, I'm also seeing some of the same alignment/illegal instructions on my lucid chroot on the beagle...
<saeedb> NCommander: the thumb mode enable when bit 5 of the cpsr is set. anyway, I think it's better to add some prints in the do_alignment, do you want me to send you a patch?
<NCommander> saeedb, that would be nice
<NCommander> (sorry, didn't see your last message)
<saeedb> NCommander: sent to your gmail
#ubuntu-arm 2009-11-25
<ojn> Alright. Anyone here who has the patches for the lange51 kernel flavor? Seems like ARM doesn't care much about the GPL, none were provided with the systems they distributed. :(
<asac> ogra: http://launchpadlibrarian.net/35539315/buildlog_ubuntu-lucid-armel.xulrunner-1.9.1_1.9.1.5%2Bnobinonly-0ubuntu1_FAILEDTOBUILD.txt.gz
<asac> IT ;)
<asac> clearly
<ogra> yep
<ogra> i wonder if we could just start the transition away from FF already and drop all xul stuff from armel to get the image building
<asac> hmm ... unlikely ;)
<asac> i can quickly upload xul
<ogra> for A1 the only target is "make it boot"
<asac> i just want to know how to best test for target being v7
<asac> i could probably check whether we are on lucid
<asac> + armel
<ogra> right, but you dont know for which files you have to add the IT hack in rules
<asac> ogra: everywhere ;)
<asac> i mean ... there are just a few files that have assembler
<ogra> oh ... hmm, indeed
<asac> i would have thought it doesnt hurt to add it
<asac> obviously hiding stuff
<ogra> no, it doesnt, and eventually the toolchain will use the IT flag by default anyway
<asac> maybe i should file an upstream bug so it doesnt get lost ;)
<asac> right
<asac> so just on top level rules: if lucid + armel -> use it
<ogra> which makes it only temporary anyway
<ogra> right ...
<asac> ogra: ok what exactly was that flag?
<ogra> CFLAGS+=-Wa,-mimplicit-it=thumb
<asac> thx
<asac> wonder if i should also add that to CXXFLAGS
<asac> probably better-safe-than-sorry ;)
<ogra> well, given that xul dies in a cpp file ...
<ogra> i wonder when doko will be back ... so the defaults change
<asac> doko probably takes extensive holiday ;)
<asac> as usual after UDS
<ogra> well deserved
<asac> yep
<ogra> but if its to extensive we should actually start a list with packages we added that workaround to :)
<asac> dyfet``: did you merge the ssd spec in the other blueprint?
<asac> somehow the url isnt valid anymore ;) ... so unless you say you didnt do anything i will assume its now properly merged?
<asac> ogra: you think that option would hurt on compilers that dont support it?
<asac> e.g. can you try on a karmic compiler?
<asac> hmm it fails becaues of unrecognized option
<asac> too bad
<ogra> yeah
<ogra> it might work on karmic if you add the other options too ... -march=cortex-a8 at least
<ogra> but then it might produce incompatible binaries, not sure what it implies for the binaries
<dmart> Can anyone suggest the best way for me to suggest resolutions for build failures?  Should I raise a bug, or something else?
<dmart> apex and ffmpeg should be built with -marm
<dmart> (apex is a bootloader, with low-level hacks which won't work with Thumb-2 without porting; ffmpeg contains a lot of optimised assembler)
<ogra> dmart, apex is used only on nslu2 ... so i didnt bother to fix it yet
<ogra> i'll add the -marm and i think it also needs a -march option to build for v5
<ogra> dmart, the proper way is indeed to file a bug, or if you can catch someone here to add a quick fix just use the shortcut through IRC
<dmart> ogra: OK
<dmart> Did we agree a standard tag for the v7/T2 migration issues?
<dmart> I will start tagging with "armv7", though we can change that later if needed.
<talat> hi all,
<talat> I open Ubuntu Q&A website - http://www.ubuntu-tr.net
#ubuntu-arm 2009-11-26
<ogra> grmbl ...
<ogra> i start to dislike apex ...
 * ogra gives up for the day ... at least we have a proper uboot for imx51 now ...
<armin76> yey
<ojn> It's pretty sad when u-boot is considered an upgrade. :)
#ubuntu-arm 2009-11-27
<tony__> can someone tell me how well ubuntu runs on beagleboard and what programs are avaliable? thanks
#ubuntu-arm 2009-11-28
<asac> chromium build still going on arm/karmic ... http://identi.ca/notice/15699986
<armin76> asac: its going to fail
<asac> no :)
<asac> place your bets :)
<asac> good that armin76 is here :)
<armin76> asac: if you're talking about building natively, its going to fail
<armin76> i tried it already
 * lool bets on armin76!   ;-)
<armin76> asac: also i hope if you're building it natively, that you have a lot of ram/swap
<armin76> 512m of ram is not enough
<asac> armin76: what build flags did you try?
<asac> i have 8g swap :)
<asac> we dropped nacl stuff and also disabled v8 snapshotting now ... still building after 1.5h :) ... not sure how long it would take though ... probably like 18h
<armin76> asac: failed for me at 5 hours @ 1.0GHz
<armin76> asac: i did what that doc said as well
<asac> ok :)
<asac> we will see
<armin76> it failed because it tried to build due to wanting to compile a file with sse2 stuff
<asac> i am not really confident that it will work :)
<armin76> err
<armin76> it failed due to wanting to compile a file with sse2 stuff
<asac> hmm ... maybe a bad snapshot? :)
<asac> anyway lets see ... if you say that it took 5 hours we are probably still a bit away :)
<asac> did you file a bug?
<armin76> asac: upstream hasn't tested it natively, so thats kinda explains it :)
<armin76> nope i haven't, i have to do other stuff
<asac> lame
<asac> so thats why i am doing this now :)
<armin76> like for example, fixing ff on sparc, which you haven't done! :)
<asac> sparc is close to zero prio :2~)
<asac> for me at least ;)
<asac> i am not even sure that ubuntu desktop can be installed atm for sparce
<asac> can it?
<armin76> no clue, no ubuntu here :)
<armin76> anyway, let's keep on topic :)
<asac> armin76: what arm board are you testing on?
<armin76> asac: i tested it on sheevaplug and mv78100 with 3g of ram, all of them armv5te, i don't have the luck you guys have :)
<armin76> fta: you work for ubuntu now?
<fta> for ubuntu? if you mean for canonical, no
<armin76> yep
<armin76> http://ubuntuforums.org/showthread.php?p=8164532 <- lolz
<cwillu_at_work> rootstock question:  I'm being prompted for the root password to log into a maintenance shell, but it's not matching the one I entered when I made the image.  Is this a useful place to ask?
<cwillu_at_work> I'm actually puzzled as to why it's asking for a password at all
 * cwillu_at_work pokes ogra with a stick
 * cwillu_at_work hacks at /etc/shadow
 * cwillu_at_work parties like it's 1969
<asac> cwillu_at_work: file a bug ;)
<asac> https://edge.launchpad.net/ubuntu/+source/rootstock/+filebug
#ubuntu-arm 2009-11-29
<armin76> asac: did it bumb? :D
<asac> armin76: the build failed ... but but but ... i dont see any error ;)
<asac> worst case i would say ;)
<asac> let me try to get the log somewhere
 * lool wins  \o
<lool> asac: Was a date set to move armel to archive.u.c?
<asac>  http://people.canonical.com/~asac/tmp/chromium-browser_4.0.260.0~svn20091128r33239-0ubuntu1~ucd1_armel.build.bak.bz2
<asac> lool: ^^
<asac> no error ;)
<asac> but still build failed
<asac> i ran the last command you can se there ... linked fine ;)
<asac> not sure whats going on
<asac> i guess OOM ;)
<asac> lool: not sure that it was discussed. was that prediscussed/should i add that as a lucid goal?
<lool> asac: scons: *** [/home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/sconsbuild/Release/obj/icu/icudata/linux/icudt42l_dat.o] Error 1
<lool> as -o /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/sconsbuild/Release/obj/icu/icudata/linux/icudt42l_dat.o /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/third_party/icu/linux/icudt42l_dat.s
<lool> /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/third_party/icu/linux/icudt42l_dat.s: Assembler messages:
<lool> /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/third_party/icu/linux/icudt42l_dat.s:2: Error: junk at end of line, first unrecognized character is `,'
<lool> /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/third_party/icu/linux/icudt42l_dat.s:5: Error: unrecognized symbol type ""
<lool> asac: Doesn't look like oom to me
<asac> oh
<asac> darn chromium build system
<asac> --keep-going
<asac> what a bad invention ;)
<asac> i looked from the back ;)
<lool> --keep-going is called from the rules
<asac> yes
<asac> thats the bad thing
<lool> So you could trash it, it's not scons' default
<asac> i dont know why fta has it
<asac> sure
<asac> already done
<lool> Well if you know it's there, I find it helpful
<asac> also did it before, just took latest snapshot and forgot to remove that
<asac> why would you want to keep going? because scons is too slow to do quick incremental builds?
<lool> The nice thing is that you know there is only this one error from everything which could be build in this pass; perhaps other errors will popup later, but it tested a good part of the build already
<lool> You might want to "fire the build and forget" and then look back at all errors, especially on random arches
<lool> (on buildds)
<lool> It's a compromise because it also wastes a lot of machine time if things go wrong every time; if you do fix build failures, it saves machine time though
<lool> Anyway, matter of taste
<asac> right
<asac> jocote:/tmp/icudt42l_dat.s
<asac> lool: ^
 * asac gets coffee ;)
<lool> asac: I'd disable stack protection for now; it seems to be broken in the toolchain here; would be nice to keep the test case though
<armin76> asac: who won? :)
<lool> asac: Just pass -fno-stack-protector
<lool> in CFLAGS
<lool> armin76: You're a gentoo guy right?
<giorgio__> Hi
<armin76> lool: yep
<lool> armin76: I find http://www.gentoo.org/proj/en/hardened/gnu-stack.xml really nice
<giorgio__> to build my ubuntu-arm image for beagle board, should i have ubuntu on my development PC (i.e. to be compatible with rootstock) or i can use kubuntu without problems ?
<lool> armin76: What do you work on in gentoo?  arm porting?
<giorgio__> i would save time to install ubuntu
<armin76> lool: we're nice ppl :P
<lool> giorgio__: kubuntu should be just fine
<giorgio__> i'm asking 'cause i cannot fetch rootstock from apt-cache search
<armin76> lool: http://armin762.wordpress.com/about/
<lool> giorgio__: kubuntu and ubuntu are built from the same underlying packages, just a different selection / default config, so worst case you have to install a couple more packages
<lool> giorgio__: Which release are you on?
<giorgio__> i installed an old one, and the let it upgrade itself, it should be kubuntu 9.04
<giorgio__> maybe i have tu follow the instruction for Jaunty ubuntu ?
<lool> armin76: good to know, thanks
<lool> giorgio__: rootstock is shipped in ubuntu/kubuntu since karmic
<lool> giorgio__: So either upgrade to karmic (you'll have to at some point anyway   ;-) or add the rootstock jaunty PPA to your config
<lool> giorgio__: Also note that rootstock is in universe, so this needs to be enabled (isn't by default)
<giorgio__> ok thanks, i'm following the instructions for jaunty, i think should not be different
<giorgio__> hope difficult either :D
<lool> asac: I can't figure why "," would be an invalid char; it seems fine from the example in http://www.gentoo.org/proj/en/hardened/gnu-stack.xml
<armin76> icu sucks
<armin76> 4.2.1 fails for me on arm, i think it was assembler related thing as well
<armin76> haven't had time to look at it
<armin76> but on debian it built fine...
<asac> lool: using @progbits helps
<asac> err
<asac> %progbits ;)
<asac> like on the gnu-stack.xml
<asac> http://paste.ubuntu.com/331089/
<asac> does that make sense ;)?
<asac> %object i did too ;)
<lool> asac: Yeah I spotted the @ versus %, but other examples say @; not sure what it means
<asac> lool: i changed %progbits and %object ;) ... whats the difference ;)
<asac> wow ... really huge .s file ;)
<asac> 6M gzipped ;)
<asac> lool: so @ works on x86 ... but % works too
<asac> readelf -S looks identical at least
<asac> lool: where is a @ example?
<asac> https://svn.pardus.org.tr/pardus/2009/stable/system/devel/gcc/files/note-gnu-stack.dpatch
<asac> seems %progbits is used for arm stuff
<asac> everywhere else its @objcet
<asac> err @progbits
<asac> too bad i dont have lucid chroot
<asac> lool: i assume you have no lucid toolchain on your board and you could check whether thtas still needed?
<armin76> asac: i won!
<armin76> now you owe me an armv7 board
<asac> armin76: we will see ;)
<asac> armin76: i am still convinced your talent would be better invested in the ubuntu project ;)
<asac> now the build is at linking stage
<asac> i guess that will consume all damn mem and swap together ;)
<asac> "Note on targets where the @ character is the start of a comment (eg ARM) then another character is used instead. For example the ARM port uses the % character."
<asac> lool: ^
<asac> http://sourceware.org/binutils/docs-2.20/as/Section.html#Section
<asac> ok that explains it ... guess we need and #if defined...
<asac> but which one ;)
<lool> asac: I dont have a lucid host yet
<lool> asac: What is that .s generated from?
<asac> good question ;)
<asac> let me check
<lool> From ./build-tree/src/third_party/icu/source/data/in/icudt42l.dat
<asac> i dont see where it gets generated
<lool> It might be pregenerated in the tree
<asac> right thats what i think
<lool> It's really slow to unpack lzma though
<lool> -rw-r--r-- fta/fta    25347229 2009-11-26 16:02 src/third_party/icu/linux/icudt42l_dat.s
<asac> so we either need to hope that % really works everywhere
<lool> It is pregenerated
<armin76> chromium's build system sucks :P
<asac> or we have to ship two different files ;)
<asac> % works at least here on x86
<asac> feels ugly though if gnu docs say @ ;)
<lool> asac: It might mean something else on x86?
<asac> lool: the readelf looked identical at least ;)
<lool>          # These are hand-generated, but will do for now.  The linux
<lool>          # version is an identical copy of the (mac) icudt42l_dat.s file,
<lool>          # modulo removal of the .private_extern and .const directives and
<lool>          # with no leading underscore on the icudt42_dat symbol.
<lool>         'linux/icudt42l_dat.s',
<asac> right.... but _how_ are they hand generated ;)
<lool>     - {mac,linux}/icudt42l_dat.s : Built on Mac and Linux with all the
<lool>       patches above applied and checked in.
<lool>     - source/data/in/icudt42l.dat : Built on Linux with all the patches
<lool>       above applied,
<lool> 11. Pre-built data libraries are checked in.
<asac> i see that section
<lool> build-tree/src/third_party/icu/README.google
<lool> Given that it's to put this in a symbol in a .o, I wonder whether they could generate a C file instead
<asac> yes. but you have to wrap each line with asm("... right?
<lool> I think it's just data; they could export a const array
<lool> The declaration says it's not executable anyway
<lool> So something like unsigned long data[] = {0x...};
<asac> hmm
<lool> + static
<lool> It's in section .rodata, so clearly const
<asac> yep
<lool> .align 8 => can probably be achieved with __attribute__
<lool> Not sure what .type icudt42_dat,%object means
<asac> i asked on the #chromium channel now ... lets see if anyone answers
<asac> http://sourceware.org/binutils/docs-2.20/as/Type.html#Type
<lool> "Mark the symbol as being a data object. "
<lool> Right just landed on that page as well
<asac> hmm so STT_OBJECT?
<lool> Does this exist in C?
<lool> I'm not even sure this stuff is needed
<asac> ok STT_OBJECT works
<lool> in C?
<asac> no in .s
<asac>         .type icudt42_dat STT_OBJECT
<asac> rather than ,@object
<asac> doc says thats the gnu arch independent way
<lool> Well yes, that's the same thing
<asac> that reduces the problem to the progbits ;)
<lool> I was proposing to move this whole .s stuff to .c to aovid the porting issue
<asac> which doesnt really help :)
<asac> right
<asac> i understood
<lool> Oh the object part was rejected as well?
<asac> yes
<asac> @ is a comment on arm asm
<lool> Ok didn't see that far
<lool> Right
<asac> Note on targets where the @ character is the start of a comment (eg ARM) then another character is used instead. For example the ARM port uses the % character.
<asac> http://sourceware.org/binutils/docs-2.20/as/Section.html#Section
<asac> hell ... i want a portable for that too ;)
<lool> Yup, read that too; just didn't spot use of @ in object
<asac> or know how the .s is generated so we can create a .c
<asac> ah ok
<lool> Well to me it seems the .s is just the bytes from the .dat
<asac> #chromium channel folks are laggers ... noone replying sundays as it seems ;)
<lool> haha
<asac> yes. but there must be  ascript or something ;)
<asac> so we want to use static unsigned long icudt42_dat[] { .... } ?
<asac> feels like we could even postprocess that from the .s file ;)
<asac> echo "const unsigned long icudt42_dat[] = {" > out.c; grep ^\.long icudt42l_dat.s | sed -e 's/\.long//' | sed -e 's/$/,/' >> out.c; echo '};' >> out.c
<asac> might complain about final , ;)
<asac> lool: isnt the alignment automatically done by gcc?
<lool> asac: Only on size long
<asac> hmm
<lool> It might be more, but how do you know?
<asac> so __attribute__ ((aligned (8))); ?
<lool> Yup
<asac> echo "const unsigned long icudt42_dat[] = {" > out.c; grep ^\.long icudt42l_dat.s | sed -e 's/\.long//' | sed -e 's/$/,/' >> out.c; echo '} __attribute__ ((aligned (8)));' >> out.c
<lool> I checked build-tree/src/third_party/icu/linux/icudt42l_dat.s, it starts with the same bytes as build-tree/src/third_party/icu/source/data/in/icudt42l.dat
<asac> hmm
<asac> ok so we could write the full binary generator
<asac> isnt there such a tool already ;)
<asac> must be somewhere
<lool> asac: FYI, the conversion is completely unportable like this
<lool> It uses long despite the fact that it's represented differently on little endian and big endian arches
<lool> I think we just want some uint8_ts
<asac> maybe the code consuming this does the endianess shuffeling?
<asac> do we know?
<lool> I have my doubts
<asac> why is ICU such a mess ;)
<giorgio__> do you know anything about touch screen issues with the beagleboard ?
<lool> I did a grep -rl icudt42_dat build-tree/src/* but couldn't find where the symbol was used exactly
<asac> heh
<lool> asac: and the end of the file is also the same
<asac> right
<asac> thats expected (now)
<asac> so the gcc on the out.c runs for 5 minutes already ;)
<asac> ok to be fair chromium is linking in the background ;)
<lool> 10515 asac      20   0  494m 140m   84 R  1.3 29.8   1:56.70 cc1
<asac> yep ;)
<asac> thats the out.c one
<asac> as was much faster ;)
<lool> I'm just scared with the memory use
<asac> yeah. probably HUGE array gets parsed first
<asac> let me abort that for now
<asac> give some air to breath to ld
<asac> ;)
<lool> ld is also hungry
<lool>  8683 asac      20   0 1245m 352m   76 D  3.2 74.7   5:59.52 ld
<asac> right
<asac> but thats expected
<asac> chromium takes like 3G
<lool> wow
<asac> we only have 512m :(
<asac> for linking
<asac> it links everything static
<asac> and does that for 1000 binaries or so ;)
<asac> all tests etc.
<asac> lool: did you succeed with your full/dynamic arm chroot thing?
<lool> I stopped at UDS
<asac> kk
<lool> I need to finish this
<lool> I clearly didn't manage to avoid binfmt though
<lool> It might be possible with some awful hacks
<fta> most chromium devs use gold instead of regular ld, but i don't know for arm
<asac> do you know where this icu blob is actually used ;)?
<asac> icudt42_dat
<fta> Assembling /build/buildd/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/sconsbuild/Release/obj/icu/icudata/linux/icudt42l_dat.o
<fta> Creating library /build/buildd/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/sconsbuild/Release/lib/libicuuc.a
<asac> yes
<lool> asac: No, as I said above I grepped for it and couldn't find it
<asac> right thats why i asked fta ;)
<asac> (sorry for missing nick)
<lool> I found it referenced in other .a files, but I didn't see where the symbol was used
<lool> Oh sorry
<asac> lool: referenced in other .a files?
<asac> which one?
<lool> Sorry off buffer
<lool> grepping again
<asac> :)
<giorgio__> wich is the newest kernel version and where i can get the link to pass to rootstack ?
<fta> http://code.google.com/p/chromium/issues/detail?id=22369
<lool> giorgio__: We dont support beagleboard kernels sadly
<lool> build-tree/src/sconsbuild/Release/lib/libicuuc.a
<lool> build-tree/src/sconsbuild/Release/lib/libicudata.a
<lool> asac: ^
<lool> it continues
<asac> nm on those?nm build-tree/src/sconsbuild/Release/lib/libicuuc.a | grep icu.*_dat U icudt42_dat
<giorgio__> lool: i found it, simply navigate in the rcn-ee.net website
<giorgio__> tnx anyway
<asac> nm ./build-tree/src/sconsbuild/Release/lib/libicudata.a
<asac> icudt42l_dat.o:
<asac> 00000000 R icudt42_dat
<lool> build-tree/src/sconsbuild/Release/obj/icu/icuuc/source/common/udata.o
<lool> build-tree/src/sconsbuild/Release/obj/icu/icudata/linux/icudt42l_dat.o
<lool> Oh right it's mentionned in some tests as well
<asac> build-tree/src/third_party/icu/source/common/umapfile.c:#       define U_ICUDATA_ENTRY_NAME "icudt" U_ICU_VERSION_SHORT U_LIB_SUFFIX_C_NAME_STRING "_dat"
<asac> lool: ^
<asac> so U_ICUDATA_ENTRY_NAME
<armin76> lool: why don't you support beagleboard?
<asac> loaded question i guess
<asac> we provide rootstock ;)
<fta> asac, lool: which version are you using, in r30145, there's a fix for icu on arm, but 1 month old now
<armin76> asac: did you saw the link fta posted?
<asac> fta: I use latest daily
<asac> fta: link to that commit?
<fta> hmm
<armin76> asac: but thats not commited?
<asac> maybe icu snapshot wasnt bumped to latest?
<armin76> oh, it is
<armin76> well, i don't understand google code :P
<fta> here is the patch http://codereview.chromium.org/338031
<asac> is icu a copy? not a on-demand checkout?
<asac> ok
<asac> heh
<asac> yes
<asac> thats the fix
<asac> though .type icudt42_dat STT_OBJECT is "better" ;)
<fta> i know, but it's strange you still see it though
<asac> fta: why isnt that in daily?
<asac> guess it wasnt committed?
<fta> it was, as i said, it's in r30145
<asac> when was it backed out ;)?
<asac> when they merged icu?
<asac> can you confirm that its not in anymore? or is our tarball bogus?
<fta> checking
<lool> asac: http://paste.ubuntu.com/331166/
<asac> yeah
<asac> 17:18 < asac> build-tree/src/third_party/icu/source/common/umapfile.c:#       define U_ICUDATA_ENTRY_NAME "icudt" U_ICU_VERSION_SHORT U_LIB_SUFFIX_C_NAME_STRING "_dat"
<asac> 17:19 < asac> lool: ^
<asac> so grepping for U_ICUDATA_ENTRY_NAME gives the usesin code
<asac> not sure if we should check if that deals with endianes properly there
<fta> chromium pulls /trunk/deps/third_party/icu42@32651 so it's in. are you sure you're patching the same file?
<asac> so this was committed to icu tree?
<asac> where i sthe tree?
<asac> (svn)
<fta> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/
<asac> thx
<lool> asac: Ah cool, that's what I would have grepped next, but I feared being overwhelmed with results
<asac> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/linux/icudt42l_dat.s?revision=32640&view=markup
<asac> fta: ^^
<asac> its clearly not on trunk anymore
<asac> i dont even see any commit backing that out ;)
<asac> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/linux/icudt42l_dat.s?r1=26784&view=log
<asac> how can i get longer log for that?
<asac> oh maybe they added it to 38?
<fta> viewvc is crap
<asac> no ... its not there either :/
<asac> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu38/linux/icudt38l_dat.s?view=log
<asac> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu38/linux/icudt38l_dat.s?revision=24730
<asac> its odd if i look at the diff to previous of the ARM portable commit
<asac> it _adds_ the @ stuff
<asac> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/linux/icudt42l_dat.s?r1=25651&r2=26784
<asac> oh ;)
<asac> its on the right
<asac> didnt even see anything of that on my screen :)
<asac> yeah. so this regressed in commit http://src.chromium.org/viewvc/chrome?view=rev&revision=29728
<armin76> reverted :)
<lool> asac: http://paste.ubuntu.com/331180/
<lool> asac: Change "L>*" to "L*" to use native encoding; "<" is LE, ">" is BE
<lool> (nothing is whatever the host runs == native)
<lool> And tweak $chunk and sprintf as you please
<armin76> lool: asac was compiling with -j8
 * armin76 runs
<asac> ?
<armin76> asac: j/k
<lool> asac: if you talk to upstream, would love if you made them generate a .s or .c at build time; it's one less large and weird sourcefile and more maintainable for us in such cases
<asac> ack
<asac> thats what we should be aiming for i guess
<fta> asac, 32640 did it
<fta> crbug.com/20406
<lool> love that URL scheme
<lool> fta, asac: So it's pretty clear the fact that the generation happens manually participated in this issue.... :-(
<lool> anyway /me runs &
<asac> enjoy
<fta> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/README.google   look at 11.
<fta> asac, i will reopen the bug
<asac> yes... already read
<fta> (i'm bugcontrol there)
<asac> fta: can you suggest to generate those on the fly?
<fta> it seems difficult based on all the changes mentioned in the readme
<asac> from what i understand the changes are done to the .dat file
<asac> so that one would be the base for mac/linux at least
<asac> which bug will you open=
<asac> there were two ;)
<asac> how much faster would chromium finish if built without tests? ;)
<asac> :-P
<fta> I build it in 20 minutes here ;)
<asac> g++ -o /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/sconsbuild/Release/ui_tests
<fta> i reopened crbug.com/20406
<asac> without comment?
<asac> hmm that bug is a different one
<asac> not the ARM regression bug
<fta> oops, crbug.com/22369
<fta> bad paste buffer
<asac> http://code.google.com/p/chromium/issues/detail?id=22369
<fta> asac, anything else broken on arm?
<asac> cant tell ;)
<asac> build is slow
<asac> linking
<asac> atm
<asac> fta: we should add armv7=1 to GYP_DEFINES
<asac> if we are on armv7 i guess
<asac> at least i added it here ;)
<fta> could you please paste a dpkg-architecture?
<asac> http://paste.ubuntu.com/331205/
<asac> doesnt show if we are on v7
<fta> uname -m?
<asac> $ uname -m
<asac> armv7l
<fta> better
<fta> do you have other flavors you want to support?
<asac> i am not sure we want to not use the uname -m ... rather something that figures if the toolchain defaults to v7
<asac> fta: i think it would be nice if it also can be compiled on armv7 machines for hardy
<asac> thats why we need to use toolchain or CFLAAGS or something to determine that
<asac> fta: i think we want to use that for lucid and later
<asac> for now
<asac> fta: tests are running ;)
<asac> ## list of FAILED tests:
<asac> [  FAILED  ] ConditionVariableTest.FLAKY_MultiThreadConsumerTest (796 ms)
<asac> [WARNING] /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/testing/gtest/src/gtest-death-test.cc:741:: Death tests use fork(), which is unsafe particularly in a threaded context. For this test, Google Test couldn't detect the number of threads.
<asac> Timeout: aborting command ``./base_unittests'' with signal 9
<asac> Killed
<asac> quite a lot tests work though
<asac> nice
<asac> chromium-browser .deb seems to be done on jocote ;)
<asac> fta: package is building -dbg .deb still ... is it normal that i see a test_shell_test process running still?
<asac> baseunit_tests too afaict
<asac> 17863 asac      20   0 77348    8    4 R 33.0  0.0  66:33.30 base_unittests
<asac> 22152 asac      20   0 47516    8    4 R 33.0  0.0  22:27.81 test_shell_test
<asac> 23507 asac      20   0  372m 368m   60 R 33.0 78.2  12:00.53 lzma
<fta> nope, should have been killed by timeout
<asac> kk
<fta> i use a timeout of 600 sec, it's usually enough to let each test run. the idea is just to prevent the build from being blocked on network accesses.
<fta> by default, the builder kills builds that didn't produce outputs for 4 hours, my stuff makes that 10 minutes minus the running time
<fta> so it seems timeout is broken on arm
<fta> could you check in the logs how base_unittests & test_shell_test ended up?
<fta> asac, ^^
<asac> fta: build is still running ;) ... but let me look
<asac> fta: http://paste.ubuntu.com/331304/
<fta> hm, fork()
<fta> i should kill those too
<fta> i guess the ppid is gone, right?
<asac> ;)
<asac> its defunct
<fta> yep, that's expected
<asac> asac@jocote:~$ ps -eaf | grep base
<asac> asac     17600     1  0 18:47 ?        00:00:24 /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/sconsbuild/Release/base_unittests
<asac> asac     17848 17600  0 18:48 ?        00:00:00 [base_unittests] <defunct>
<asac> asac     17863 17600 49 18:48 ?        01:11:33 /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/sconsbuild/Release/base_unittests
<asac> asac     25011 24437  0 21:12 pts/1    00:00:00 grep base
<asac> so can i kill them without risking the packaging stop  ;)
<asac> ?
<fta> yes
<asac> those dead tests consume 60% of CPU
<fta> lol
<asac> asac     22152     1 34 19:52 ?        00:27:57 /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/sconsbuild/Release/test_shell_tests
<asac> that is still running too
<asac> guess same boat?
<fta> if the ppid is defunct, yes
<asac> great ... funally lzma gets 70% of CPU ;)
<asac> should speed this up by factor 3 ;)
<asac> ppid was 1 ;)
<asac> 23507 asac      20   0  372m 364m   56 R 96.4 77.2  18:14.76 lzma
<asac> yay
<asac> full speed
<asac> -dbg
<asac>  ;)
<fta> could you pastebin your /proc/cpuinfo?
<asac> http://paste.ubuntu.com/331310
<fta> funny, it looks totally different from the usual format
<asac> different arch ;)
<asac> no MhZ ;)
<fta> i mean, the linux kernel usually spits something similar, same keys, different values
<asac> fta: sparc: http://paste.ubuntu.com/331313/
<fta> oh
<asac> fta: ppc http://paste.ubuntu.com/331314/
<asac> so not really much in common ;)
<asac> hmm ... do we really need lzma ;) ... someone said lzma was awefully unoptimized on arm
<asac> i see what that means atm ;)
<fta> i can disable it easily for arm, i have a knob
<fta> you will just have 30% to 50% bigger debs
<fta> but with thumb, you can produce smaller binaries, so maybe that's ~
<asac> yeah.
<asac> fta: did you commit the regressoin unpatching yet? ... also the lucid == armv7 would be great so i can copy the sources to some native ppa for lucid/karmic tomorrow?
<fta> regressoin unpatching? you mean icu?
<asac> yes.
<asac> s/@/%/
<fta> i didn't, i will kick upstream to have relanded asap
<fta> +it
<asac> kk
<asac> i think the karmic debs should be good enough to get someone trying to run those bits
<asac> to get a first idea about how broken it is ;)
<asac> but you could add the lsb_release -c == lucid -> armv7=1 thing
<asac> thats definitly wanted
 * asac can do that too
<fta> you mean, armv7 without even checking it's a v7 capable box?
<fta> WANT_TESTS = 0 too? (that's sad)
<asac> for 9.10 and above we dont support anything below v5
<asac> err v7
<asac> you could do a double check
<asac> if armv7l or better and if lucid or newer -> do it
<asac> so if someone ports lucid to armv6 or something it would still build
<asac> i think we can keep tests on
<asac> they didnt take that much time after all ;)
<asac> just a few hours ;)
<asac> maybe ensure that its easy to unset that by env
<asac> ;)
<asac> but not really important
<asac> also a variable for KEEP_GOING=0 ;)
<asac> maybe just remember to kill those processes looping if the tests fail ;)
<asac> : chromium-browser-inspector: image-file-in-usr-lib usr/lib/chromium-browser/resources/inspector/Images/warningsErrors.png
<asac> W: chromium-browser-inspector: image-file-in-usr-lib usr/lib/chromium-browser/resources/inspector/Images/whiteConnectorPoint.png
<asac> E: chromium-browser-inspector: copyright-should-refer-to-common-license-file-for-lgpl
<asac> E: chromium-browser-inspector: lzma-deb-archive
<asac> E: chromium-browser-l10n: copyright-should-refer-to-common-license-file-for-lgpl
<asac> E: chromium-browser-l10n: lzma-deb-archive
<asac> we are close :)
<fta> is it ok if i target the armv7 for ubuntu+1 instead of hardcoding lucid? i mean, lsb_release -ds matching either unstable or development to cover both debian & ubuntu
<asac> i am not sure about the target arch of debian
<asac> but if you also check for target CPU then probably yet
<asac> yes
<fta> it will match sid and lucid
<asac> (not sure what to test so we can still cross-compile )
<fta> of course, for arm(el) only
<asac> fta: i know. but i odnt know what target sid has ;)
<asac> i wouldnt necessarily say that they stop supporting armv5
<asac> would have to check with whowever has a say on that in debian ;)
<asac> lool: ?
<asac> who is that?
<asac> BUILD FINISHED ;)
<asac> \o/
<asac> cheers
 * asac gets a drunk
<asac> drink ;)
<fta> lol
<fta> does it run?
<asac> i have no local machine
<asac> lool: wanna grab the debs from jocote and try? ;)
<asac> its karmic build
<asac> JamieBennett: ogra: NCommand`: ^^
<asac> GrueMaster: ^^
<asac> ;)
<asac> ls ~asac/*.deb
<asac> xforwarding seems to be not enabled there
<asac> hmm. maybe because it goes thorugh a ssh proxy? not sure
<asac> lets hope for one of the above to test it ;)
<asac> fta: arent there tests against xvfb ?
<fta> yes, they are
<asac> e.g. couldnt i check if some test worked to see if chances are high that it works?
<asac> fta: which test would i look for?
<fta> those are unittests, so not a guaranty that the whole thing runs :(
<asac> well
<fta> test_shell would be nice, but you still need a display
<asac> [19742:19742:1129/193121:3402522844231:ERROR:/home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/base/shared_memory_posix.cc(192)] Creating shared memory in /dev/shm/com.google.chrome.shmem.unit_tests-19742 failed: Permission denied
<asac> i see a bunch of those
<asac> feels like that could be a buildd setup problem
<asac> fta: http://people.canonical.com/~asac/tmp/chromium-browser_4.0.260.0~svn20091128r33239-0ubuntu1~ucd1_armel.build.gz
<asac> thtas the full log (incremental though)
<asac> ok seems /dev/shm has not right permissions in the chroot
<asac> s -la /dev/shm/
<asac> total 8
<asac> drwxr-xr-x 2 root root 4096 Sep  9 18:48 .
<asac> but outside of chroot its fine
<asac> will check with lamont
<fta> yeah, 550 lines of d/rules file
<fta> crazy thing to build
<armin76> asac: debian hasn't dropped i486 for i686, no point they are dropping armv5
<asac> we havent dropped i486 either
<asac> :-P
<armin76> asac: are you still a debian dev?
<asac> in my non-existing spare time ... yes ;)
<armin76> asac: ok, another point: ubuntu doesn't support any publicly-available board, debian does
<asac> i know
<armin76> and they don't support any armv7
<armin76> nor anything avobe v5, for that matter
<armin76> err, above :P
<asac> not sure what point you are trying to make ;) ... the question here was if we wanted to enable armv7 for debian sid ;) ... which i said was probably not right
<asac> so you confirmed that i guess ;)
<armin76> in fact debian supports armv4t, which the untouch gcc code didn't support, for example :)
<asac> i think we support armv5 ... just not the kernel ;) ... so no image
<asac> does debian offer images for all kind of arm SoCs?
<armin76> hrm...i have no clue
<armin76> i know the installer supports them, but not sure how you get the installer
<asac> right
<asac> thats what i mean. in general we support everything (well until lucid where we now make use of modern stuff)
<armin76> asac: we as in ubuntu or?
<asac> just have no images... because we dont have kernels for all the SoCs that are out there ;)
<asac> yes
<armin76> debian has the kernels, though
<asac> armin76: which ones?
<asac> http://www.debian.org/ports/arm/
<armin76> yep
<armin76> i find funny you ask me, you being a debian dev :P
<armin76> marvell kirkwood is supported on squeeze iirc
<asac> i am not really into arm that long ;)
<armin76> also i believe they only support those devices that have kernel.org support
<armin76> anyway, let's focus on topic
<armin76> asac: you owe me an armv7 board :)
<asac> noted
<armin76> danke
<suihkulokki> debian supports only mainline kernel boards due to resource constraints
<suihkulokki> then again, any vendor claiming to support boards that are not mainlined is lying to their customers
<suihkulokki> ..in a few upstream kernel releases, the customer will find out that _they_ are not getting any kernel upgrades..
#ubuntu-arm 2010-11-29
<jacquesdptd> hey guys
<jacquesdptd> i don't know if you remind me, i came here to have info about the port i was trying to make of Ubuntu 10.10 mobile on my wits a81-e wich is a omap3 beagleboard like tablet with 256 ram
<jacquesdptd> And some helped me and told me i had to find the kernel info (android 2.2 running on it) and then change the flash booting files, to boot ubuntu from sd card as said on the Official arm Ubuntu preinstalled page
<jacquesdptd> well, i think i found what i was needing
<jacquesdptd> http://code.google.com/p/a81linux/downloads/list
<jacquesdptd> if anyone can confirm, if that are the right files, i'll try it in 5 hours cause i don't hve the time now
<jacquesdptd> but i would have liked just to have a sort of, "That's it man" thx
<henry1> No command deb in my Lucid for "deb https://wiki.linaro.org/WorkingGroups/ToolChain/CrossCompilerOnLucid". "apt-get install deb" could not find it as weel.
<StevenK> henry1: add-apt-repository "    *
<StevenK>       deb http://people.canonical.com/~hrw/ubuntu-lucid-armel-cross-compilers/ ./ "
<StevenK> Sigh, cut-n-paste fail
<StevenK> add-apt-repository "deb http://people.canonical.com/~hrw/ubuntu-lucid-armel-cross-compilers/ ./"
<henry1> Got it. But get another error: sudo add-apt-repository ppa:hrw/arm-cross-compiler
<henry1> Error: can't find signing_key_fingerprint at https://launchpad.net/api/1.0/~hrw/+archive/arm-cross-compiler
<StevenK> henry1: That doesn't work because the PPA doesn't exist
<henry1> what does PPA mean?
<StevenK> henry1: A PPA is an archive hosted by Launchpad, hrw's cross compiler is done seperately
<StevenK> henry1: Run the add-apt-repository as I typed it with a sudo in the front
<henry1> what is a full command for  "sudo add-apt-repositoryÂ ppa:hrw/arm-cross-compiler"?
<StevenK> henry1: sudo add-apt-repository "deb http://people.canonical.com/~hrw/ubuntu-lucid-armel-cross-compilers/ ./"
<henry1> got error doing "sudo apt-get update":W: Failed to fetch http://ppa.launchpad.net/hrw/arm-cross-compiler/ubuntu/dists/lucid/main/binary-i386/Packages.gz  404  Not Found
<henry1> W: Failed to fetch https://wiki.linaro.org/WorkingGroups/ToolChain/CrossCompilerOnLucid/./Packages.gz  The requested URL returned error: 404
<hrw> heh...
<hrw> people - start *reading*
<hrw> https://wiki.linaro.org/WorkingGroups/ToolChain/CrossCompilerOnLucid says exactly what sources.list line should look
<hrw> and my PPA was removed and will not come back
<hrw> ppa:hrw/arm-cross-compiler was dropped - it will not be back. eot
<rbelem> jacquesdptd, do you have the bootloader to boot from sd?
<NCommand1r> ogra: https://launchpad.net/bugs/675347 - source of Qt FTBS
<ubot2> Launchpad bug 675347 in gcc-4.5 (Ubuntu Natty) (and 2 other projects) "volatile int causes inline assembly build failure (affects: 4) (dups: 2) (heat: 32)" [High,Confirmed]
<NCommand1r> ogra_ac: did you see the above link?
<ogra_ac> nope
<ogra_ac> can you repost
<NCommand1r> 08:17:29 < NCommand1r> ogra: https://launchpad.net/bugs/675347 - source of Qt FTBS
<ubot2> Launchpad bug 675347 in gcc-4.5 (Ubuntu Natty) (and 2 other projects) "volatile int causes inline assembly build failure (affects: 4) (dups: 2) (heat: 32)" [High,Confirmed]
<NCommand1r> ^- ogra_ac
<NCommand1r> bah
<NCommand1r> and now I am me
<ogra_ac> NCommand1r, yeah, i know that one
<NCommand1r> ogra_ac: right, so if/when that gets fixed, we get transmission + libproxy fvixed
<ogra_ac> did you talk to doko ?
<ogra_ac> the last comment indicates there is a fix/workaround
<ogra_ac> by revering a patch
<NCommand1r> nope
<NCommand1r> not yet
<ogra_ac> i did on -devel
<ogra_ac> lets see what he says
<ogra_ac> i wouldnt like to miss A1
<NCommand1r> ogra_ac: I'm pretty happy to unseed transmission, and whack libproxy on armel only
<NCommand1r> then revert after milestone
<ogra_ac> NCommand1r, i would like to avoid it if possible
<ogra_ac> and looking at the ftbfs list that wont be our only probs
<NCommand1r> ogra_ac: indeed, but if all ele fails ...
<dmart> NCommand1r: do you know why understand which -fstrict-volatile-bitfields breaks this?
<NCommand1r> dmart: ECONTEXTNEEDED
<rsalveti> morning :-)
<NCommand1r> ...
<ogra_ac> ah, at least gnome-python-extras built
<NCommand1r> why did I loose my nick again?
<ogra_ac> NCommand1r, i guess dmart means the bug above
<dmart> < NCommand1r> 08:17:29 < NCommand1r> ogra: https://launchpad.net/bugs/675347 - source of Qt FTBS
<ubot2> Launchpad bug 675347 in gcc-4.5 (Ubuntu Natty) (and 2 other projects) "volatile int causes inline assembly build failure (affects: 4) (dups: 2) (heat: 32)" [High,Confirmed]
<dmart> Since _q_value isn't a bitfield in the example, I'm confused.
<dmart> I also wonder whether using _q_value twice with different constraints is causing extra confusion?
<NCommander> ogra_ac: doko said that he won't do a compiler upload until past A1
<NCommander> dmart: I'm eyeing it now
<ogra_ac> NCommander, hmm, where did he say that ?
<ogra_ac> he didnt answer in -devel
<NCommander> ogra_ac: comment on the bug
<NCommander> "please no compiler upload before alpha-1 is out
<NCommander> "
<NCommander> on 11-23-2010
<ogra_ac> hrm, k
<ogra_ac> ha!
<ogra_ac> gnupnp is off the list too
<NCommander> ogra_ac: nice, no-changes whacking is my favorite time of bug to squish
<NCommander> dmart: http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00155.html
<NCommander> I can't actually find an explaination of what the heck it does though
<dmart> NCommander: my guess is that -fstrict-volatile-bitfields causes attempts to access a volatile bitfield (which is invalid C) to be treated as an error.
<NCommander> dmart: its an optimization
<NCommander> I found half a code comment in a diff
<NCommander> I just downloaded GCC to get the rest of said comment
<dmart> The patch you mention seems to be related to an optimisation where a bitfield is accessed with a normal access (say to access 8 nicely aligned bits within a word)
<NCommander> dmart: its in the documentation (which isn't on the website)
<NCommander> give me five minutes and I'll pastebin it
<dmart> ok
<NCommander> dmart: looks like it was deleted from the documentation
<NCommander> WTF
<NCommander> dmart: http://paste.ubuntu.com/537908/
<NCommander> Correction, in SVN only
<NCommander> dmart: I get why this was enabled, but non-aligned access is supported for v6 and greater, right?
<Tscheesy> rbelem: re - thx.. i guess you missunderstod me - uboot is installed - the nitdroid-Kernel you mentioned is my Problem.. i do not have a u-boot-Image from this Kernel ;)
<rbelem> oh!
<Tscheesy> only the source - but i can't compile it though no running Nitroid on n900 here
<rbelem> Tscheesy, are your n900 running pr1.3?
<Tscheesy> yes
<Tscheesy> u-boot works fine
<rbelem> Tscheesy, Tscheesy you can download the nitdroid kernel in binary form. let me check the link
<Tscheesy> ah - i read that Notdroid uses Multiboot - did you find a u-boot Binary? or is it the same?
<rbelem> Tscheesy, you can use the same binary
<Tscheesy> ahh
<rbelem> Tscheesy, you need to copy the modules to /lib/modules/<kernel-version>
<rbelem> from nitdroid
<Tscheesy> those fromm meego?
<Tscheesy> a k
<rbelem> Tscheesy, from the nitdroid rootfs
<Tscheesy> ok - the Kernel itself?
<Tscheesy> also then?
<Tscheesy> i'll get a Nitroid rootfs then.. thx
<rbelem> Tscheesy, the kernel and the modules
<rbelem> Tscheesy, you can install nitdroid to the external sd, copy the needed files to the ubuntu rootfs
<Tscheesy> ok .. saw screenshot from kubuntu-mobile recently on kubuntu-twitter i guess
<rbelem> :-)
<Tscheesy> i'll changeroot into nitdroid rootfs - should work though
<dmart> NCommander: http://paste.ubuntu.com/537908/> thanks
<dmart> I don't understand which this is biting us though - the _q_value field in the example attached to the bug is a naturally aligned int
<dmart> -fstrict-volatile-bitfields (or the absence of it) should be irrelevant to this case ...?#
<NCommander> dmart: is it possible the compiler is generating a false positive and bombing out where it shouldn't?
<dmart> I guess
<dmart> There are some possible oddities in the contraints for the inline asm--- I suggested some possible alternatives in the bug, but I'm not convinced it's wrong as-is or that my changes will improve matters...
<NCommander> it clear though the correct solution isn't to back out this change
<ScottK> NCommander: It depends.  How long are you going to leave the toolchain broken?
<NCommander> ScottK: not sure, still reading.
<NCommander> ScottK: the change in GCC is correct because the ARM ABI says that you shouldn't to unaligned accesses (you can on newer harder, but the current ABI predates that)
<ScottK> NCommander: Reverting to gcc-4.5 4.5.1-9ubuntu1 would solve my problem very nicely.
<NCommander> ScottK: and mine, but its the wrong fix unfortunately, and doko has said no toolchain uploads for A1
<ScottK> Except of course for the one he did after he said that.
<NCommander> ScottK: file a bug on doko then
<ScottK> NCommander: I know it won't get fixed for Alpha 1.  I'd just like it fixed eventually (where eventually is early enough in the cycle we can still do something useful)
<ogra_ac> NCommander, i still dont see wheer he said that, its not on the bug
<NCommander> ogra_ac: https://bugs.launchpad.net/gcc-linaro/+bug/675347/comments/20
<ubot2> Launchpad bug 675347 in gcc-4.5 (Ubuntu Natty) (and 2 other projects) "volatile int causes inline assembly build failure (affects: 4) (dups: 2) (heat: 32)" [High,Confirmed]
<ogra_ac> oh, thats ages ago
<Tscheesy> Hi - as i understand the nitroid installation has no Kernel itself and the multiboot-Kernel is installed on maemo? - i do use u-boot (wan't to install kubuntu-mobile) and just need the kernel and the modules ( /lib/modules/<kernel-version> )
<Tscheesy> ups - wrong chan
<Tscheesy> this goes to #nitdroid
<rbelem> :-)
<berco> ogra_ac: do you have the kernel from -proposed running? if yes, what do you have in /proc/asound/cards?
<ogra> berco, ogra@panda:~$ cat /proc/asound/cards
<ogra>  0 [Panda          ]: OMAP4 - Panda
<ogra>                       TI OMAP4 Board
<ogra> alsactl matches for Panda or Blaze now
<berco> ogra: looks like in our most recent kernel we miss the OMAP4 name
<rsalveti> hm, not that sure
<rsalveti> berco: latest on maverick's main is 2.6.35-903.17, that contains the audio patches already
<rsalveti> or am I missing something?
<berco> ogra: rsalveti: I think I understand my pb. I lend my board and the guy changed my kernel. I don't have the pb on my panda, only on blaze
<rsalveti> proposed is 2.6.35-903.19, and just has 2 unrelated fixes
<berco> which I lend
<rsalveti> oh, ok
<berco> rsalveti: ogra: updating alsa-utils from 1.0.23-2ubuntu3 to 1.0.23-2ubuntu3.4
<berco> still gives me errors with the right kernel
<berco> I have the following 3 lines
<berco> sudo bash -c "sudo echo performance >Â /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor"
<rsalveti> hm, the error was expected only with the released kernel
<berco> oops sorry, wrong copy/paste
<berco> No protocol specified
<berco> xcb_connection_has_error() returned true
<berco> Home directory /home/ubuntu not ours.
<rsalveti> :-)
<rsalveti> berco: and are you trying this on blaze or panda?
<berco> rsalveti: I'm on panda right now
<rsalveti> berco: what error are you getting? post inst fail?
<rsalveti> if so, the problem is the alsactl init
<rsalveti> that should happen only with the older kernel
<berco> rsalveti: posinst is failing for me b'cos of the alsactl init
<rsalveti> berco: what is your kernel version?
<berco> rsalveti: if I remove the call to alsactl init I don't see the issue
<berco> rsalveti: 2.6.35-980-omap4 #1release3
<rsalveti> berco: yeah, I also got that some time ago, ogra_ac was looking for the proper fix
<rsalveti> and the 3.4 got on main wrongly
<rsalveti> hm, your own kernel
<berco> well, TI internal kernel
<rsalveti> proc/asound/cards matches with what oliver got?
<berco> but I verified, we do have the changes and it matches ogra's output for proc/asound/cards
<rsalveti> berco: what is your error message?
<berco> rsalveti: here is my output http://pastebin.ubuntu.com/537969/
<rsalveti> berco: your alsa-utils is not complaining about the lack of a proper machine name
<rsalveti> but is giving 3 error messages I never saw
<rsalveti> weird
<berco> rsalveti: no. This was the issue I had with my wrong kernel running on my blaze. Sorry about this confusion.
<rsalveti> ok
<berco> rsalveti: I tried "sudo alsactl init" -> it gives me similar error. If I run without "sudo" no issue.
<Tscheesy> hm .. damaged Superblock on my install of the preinstalled-kubuntu-mobile port fÃ¼r omap3 ?? so then.. once again..
<Tscheesy> (but zcat didnot work here - i had to dd the image on the sd-card - which could have caused that)
<rsalveti> berco: so if you just update it, it's not going to use sudo, then you're fine
<hrw> https://bugs.launchpad.net/bugs/682742 looks like duplicate of bug 675347
<ubot2> hrw: Bug 675347 on http://launchpad.net/bugs/675347 is private
<ubot2> Launchpad bug 682742 in gcc-4.5 (Ubuntu Natty) (and 2 other projects) "volatile int causes inline assembly build failure (affects: 4) (dups: 2) (heat: 32)" [High,Confirmed]
 * hrw out
<berco> rsalveti: I'm not sure I understand the procedure. How do you update alsa-utils?
<ogra> Tscheesy, why/how did zcat not work ?
<ogra> berco, update-manager runs as root
<rsalveti> or even apt-get upgrade
<ogra> yeah
<berco> rsalveti: ogra: ok. So you mean if I go through update-manager, it will work? When I do apt-get upgrade, it asks me for root privileges...
<ogra> thats fine
<Kamondelious> is the uvc driver not available for ubuntu-arm?
<berco> ogra: rsalveti: going through update-manager worked. So for people like me who use apt-get install, it won't
<Kamondelious> sorry, i'm behind myself
<rsalveti> berco: apt-get should work the same way
<rsalveti> as it runs as root
<ogra> berco, if it doesnt, file a bug
<ogra> (a new one)
<berco> ogra: ok. I use "sudo apt-get install alsa-utils" it shows me those 3 lines of error. Updating via update-manager, it also asks for "root" password but I don't see any error in the UI or in /var/log/dpkg.log
<ogra> berco, might be an issue with sudo or some such
<ogra> use ubuntu-bug sudo to file it and see, there might be one already
<rsalveti> maybe you changed your sudo settings  or something like that
<rsalveti> try apt-get after getting a root session with sudo su -
<tmzt_g2root> is there a good graphical installer for arm devices using X?
<ogra> tmzt_g2root, its preinstalled on our omap/omap4 images
<ogra> we use it by default
<tmzt_g2root> I'm building something like wubi for android phones and I would rather start with an existing framework
<tmzt_g2root> ah, ok. what packages would I see to do that?
<tmzt_g2root> seed
<ogra> oem-config-gtk
<Tscheesy> ogra: zcat then sync - sd-card was still empty (unmounted state..)
<ogra> Tscheesy, and you had the quoting right for the sudo command ?
<ogra> thats critical and i can imagine that people get it wrong
<Tscheesy> i'll give it another try :)
<Tscheesy> first i wrote a few devices :D
<Tscheesy> but >/dev/mmcblk0 should work imO
<berco> rsalveti: sudo su -; apt-get install alsa-utils
<berco> rsalveti: same error
<berco> rsalveti: well, almost. I don't see the /home/ubuntu is not ours ... message
<berco> only first 2 lines of errors in this configuration
<rsalveti> weird, don't know why you're getting an error message from xcb
<rsalveti> try to trace it, to see where it uses xcb and when you're getting these errors
<ogra> i dont really get where it gets the /home/ubuntu from
<ogra> that looks like boarkage with our image
<rsalveti> seems the sudo configuration is broken somehow
<berco> rsalveti: ogra: I haven't changed my sudo config. Are you not seeing this error?
<ogra> well, that still doesnt explain why it looks for 7home7ubuntu
<ogra> such users shouldnt exist on our images
<ogra> looks somewhat like a live image
<berco> ogra: I created ubuntu user at install time
<berco> when you first run the setup it will prompt you for a user name. I always call it "ubuntu" :)
<rsalveti> berco: I'm not having this issue here
 * ogra neither
<berco> using apt-get install?
<ogra> i wonder if teher is something messing with that username in oem-config
<ogra> since that name is usually the live user
<rsalveti> I usually use ubuntu for every user here :-)
<rsalveti> and it works fine
<ogra> k
<rsalveti> as does GrueMaster_
<berco> I can try with a different user as I also created a "berco" one :)
<ogra> i never use ubuntu nor admin as names :)
<naveensr89> hi..
<naveensr89> i'm having problems with installing ubuntu on beagleboard.
<naveensr89> while installing its giving migration assistant error 141.
<naveensr89> need help.
<GrueMaster_> rsalveti: I heard my name.  what's up?
<rsalveti> GrueMaster_: hey, berco is having issues with his sudo and apt-get
<rsalveti> we were thinking if using the user as ubuntu could lead to the error
<rsalveti> but I also use it here and I believe you also use it while testing the images
<rsalveti> user = user name
<GrueMaster_> Looking at the command he posted in scrollback, he has a ; between sudo and apt-get, so apt-get is not running as superuser.
<tmzt_g2root> ogra: anything that supports debian-installer tasks, parted, etc. I need to manage loop images, not so much the user name
<GrueMaster_> And the password should be the user password.  There is no root password.
<ogra> tmzt_g2root, well, then ubiquity
<tmzt_g2root> I can run that fullscreen without launching a desktop?
<tmzt_g2root> wow #ubuntu-installer
<ogra> if you have "only-ubiquity" on the cmdline
<tmzt_g2root> command line? will upstart even run in a chroot?
<tmzt_g2root> usefully
<tmzt_g2root> ah, what did you say in these slides about images expanding on first boot? is that using an initrd?
<tmzt_g2root> slides: omap_talk.ppt
<berco> GrueMaster_: rsalveti: I just created a new user and I still experience the same issue.
<rsalveti> probably an issue with your system
<rsalveti> berco: can you trace it to see when you're getting these errors?
<GrueMaster_> Creating a new user does not automatically enable them as a sudoer.
<GrueMaster_> Try using the original account that was first created.
<berco> GrueMaster_: Shall I add this user to "sudo" group?
<berco> My "ubuntu" user is not in "sudo" group either as far as I can see
<GrueMaster_> Type "groups" to see what groups it is in.  It needs to have the admin group.
<berco> My new user is called "ob1" and groups command:
<berco> ob1 adm dialout fax cdrom floppy tape dip video plugdev fuse
<GrueMaster_> What user account did you use to create the new user with?  That action can only be done by an admin.
<berco> GrueMaster_: so I used my "ubuntu" user which has been created during the install in order to create the "ob1" user
<GrueMaster_> Ok, so log in as ubuntu and see what groups it has.
<berco> for "ubuntu" user, groups are:
<berco> chipsets adm dialout cdrom sudo plugdev lpadmin admin sambashare chipset ubuntu psir omapuntu omapa
<berco> well, I just added ubuntu to sudo group
<GrueMaster> You shouldn't need to.  The default in /etc/sudoers includes:
<GrueMaster> # Members of the admin group may gain root privileges
<GrueMaster> %admin ALL=(ALL) ALL
<berco> GrueMaster: yep, I have this in my /etc/sudoers file
<GrueMaster> So, typing "sudo apt-get install <package>" as ubuntu user should work.  The password is the ubuntu user's password.
<berco> GrueMaster: yes, it works except when I update to alsa-utils version 1.0.23-2ubuntu3.4 from 1.0.23-2ubuntu3 version
<berco> GrueMaster: error I'm getting http://pastebin.ubuntu.com/537969/
<GrueMaster> I'll check into that soon.  What is the error you are getting?
<GrueMaster> Ah.  checking.
<GrueMaster> berco: I need a little time to reorg from the holiday week.  What TZ are you?
<berco> GMT+2
<berco> France
<GrueMaster> Hmm.  I see it is after 7pm there.  Will you still be online in ~30 minutes?
<berco> GrueMaster: Adding ubuntu to the sudo group didn't help
<ogra> sudo group ?
<ogra> you mean admin group, right ?
<berco> GrueMaster: was planning to go but can try to be online in ~30 min from home
<berco> ogra: no there's both admin and sudo groups
<ogra> sudo isnt used
<ogra> ubuntu uses admin only
<berco> my user was already in admin and added it to sudo too
<berco> so it makes sense the behavior hasn't changed
<ogra> right
 * berco ok disconnecting and reconnecting from home in ~30min
<tmzt_g2root> ogra: what did you mean about the iamge resizing on first boot, is that done in an initrd?
<tmzt_g2root> is there a way to set the size?
<GrueMaster> The error you are seeing has nothing to do with permissions that I can see.  It looks like a post-install script error.
<ogra> its a cairo error
<ogra> i dont get how that could have anything to do with alsa
<ogra> http://xcb.freedesktop.org/manual/group__XCB__Core__API.html
<ogra> well, an X error at least
<ogra> not actually cairo
<ogra> tmzt_g2root, no, jasper-initramfs (the tool that does the resizing) just expands to the full free space on the SD card
<tmzt_g2root> so I need a hybrid of some kind
<ogra> anyway, time to leave for the day
 * ogra might be online later again
<JohnKiller> hi guys, i've got a IGEPv2 arm board, with ubuntu 10.10 on a 4GB sd card. Kernel version is 2.6.35.7 (created with rootstock). Everything is fine, except for wifi. iwconfig shows only loopback and ethernet. On the official wiki they say to upgrade my kernel, but how??? thanks
<berco-mac> GrueMaster: have you been able to find anything?
<GrueMaster> Not yet.  Just getting set up.  Thought I had an existing image but all my SD cards are currently in Natty debug mode.
<GrueMaster> Should have one ready soon.
<berco-mac> can you email me if you find anything?
<GrueMaster> I have a 4G SD resizing now.  as soon as I get oem-config finished, I'll be ready.  15 minutes?
<berco-mac> ok. I wait 15min :)
<tmzt_g2root> rootstock is tiny :)
<tmzt_g2root> can you leave out the user password until oem-config runs?
<GrueMaster> berco-mac: Ok, updating package lists now.
<berco-mac> GrueMaster: almost at the point where I was...
<GrueMaster> Ok, first upgrading the kernel.
<GrueMaster> Gah.  No video with new kernel on my new HDMI monitor.
<tmzt_g2root> how does this work?
<tmzt_g2root> # using fakeroot so we're able to create the base rootfs as user
<tmzt_g2root>     LANG=C fakeroot debootstrap $DEFOPTS $EXTRAOPTS $DIST $ROOTFS $DMIRROR >$DBFIFO 2>&1 &
<tmzt_g2root> what does the result look like, it has to be fixed up later? or this only works with fuseext2
<rsalveti> GrueMaster: nothing?
<rsalveti> that's weird
<berco-mac> GrueMaster: are you able to enter console mode and exit "alt+F1" then "alt+F7" ?
<rsalveti> yeah, could be a fifo underflow issue
<berco-mac> GrueMaster: we have a known issue with this kernel
<GrueMaster> Give me a second.  I had to buy a new monitor last weekend and this is the first time I have booted with it.
<GrueMaster> rsalveti: looks like an edid issue.  The monitor is a Dell SR2220L LED 21" 1080P.
<topfs2> rsalveti, just wanted to ping you regarding https://blueprints.launchpad.net/ubuntu/+spec/multimedia-arm-n-set-top-box We will be adding binary addons for xbmc in eden (next stable after the one that will be out any day). With the binary addons we will probably move codecs to addons and as such adding gstreamer for decoding will be possible
<GrueMaster> Swapping back to my 1280x1024 monitor.
<topfs2> We do use openmax currently though so not forced to use our ffmpeg. (Haven't had time to fix openmax for panda yet)
<rsalveti> GrueMaster: were you able to get anything on your screen?
<rsalveti> usually it should be just a resolution problem
<rsalveti> but need to debug it further
<topfs2> I have also looked into gstreamer overall and might be the one adding it as a decode part
<rsalveti> topfs2: awesome
<GrueMaster> Looks like a kernel issue.  Image works, but after adding -proposed and updating to latest kernel, no vid.  Not even on my old monitor.
<topfs2> So if you have any questions during the evaluation I'll be idling here also :)
<rsalveti> GrueMaster: AFAIK there was no video related change between release and proposed
<rsalveti> topfs2: nice, will ping you back then :-)
<GrueMaster> rsalveti: I'm staring at a blank screen.  Activity leds are flickering indicating activity on the SD.  Will enable console and see what I can see.
<rsalveti> GrueMaster: okey
<berco-mac> GrueMaster: have you tried this: http://omappedia.org/wiki/Ubuntu_Known_Issues#Screen_Blanking ?
<berco-mac> GrueMaster: from my exprience it resolves the issue temporarly
<GrueMaster> berco-mac: I am not seeing the same issue.
<GrueMaster> yet
<berco-mac> okay. it'll be interesting you send us the EDID info once you get some time
<GrueMaster> I think we may have a race condition with the SDP4430.
<GrueMaster> I'm seeing a ton of messages with "asoc: no valid backend routes for PCM: SDP4430 Media".
<GrueMaster> Screen is now light green pastel (ick).  switching to console and back has no effect on display output.
<GrueMaster> Need to add serial console login.  One sec.
<berco-mac> after updating the kernel package, you did the "flash-kernel" right?
<GrueMaster> That's an auto.
<rsalveti> GrueMaster: that message is normal with the released kernel
<rsalveti> after updating it, it should be fine
<GrueMaster> For logging purposes, this is kernel 2.6.35-903.19.
<berco-mac> sorry guys, I'll need to leave you 'till tomorrow.
<berco-mac> getting late here
<GrueMaster> berco-mac: Sorry I couldn't get to your issue.  I'll keep plugging away.  It is only 1pm here.
<berco-mac> GrueMaster: thanks
<GrueMaster> rsalveti: I have a serial tty up.  xrandr -d :0 looks normal.  Nothing in Xorg.0.log stands out.
<GrueMaster> Nothing in dmesg either.
<rsalveti> GrueMaster: try booting with omapdss.debug=1
<rsalveti> to see what the kernel says about your monitor
<GrueMaster> I did.  Nothing there I can see looks wrong.
<GrueMaster> dmesg
<GrueMaster> dmesg
<rsalveti> can you paste me the boot log?
<GrueMaster> damn window focus.
<GrueMaster> Only if I can type.  :P
 * GrueMaster is back to 5 monitors, and semi-confused at times.
<GrueMaster> http://paste.ubuntu.com/538104/
<GrueMaster> I was able to get video on the new monitor with a fresh image prior to updating.
<GrueMaster> I am currently back to the 1280x1024 DVI monitor I used during Maverick test cycle.
<rsalveti> GrueMaster: weird, it finds the correct resolution from the edid (1280x1024@60Hz), then suspend, resume, probe edid again and gets the correct resolution one more time
<rsalveti> without any other message
<rsalveti> after a while it did suspend again, but probably because of lack of activity
<GrueMaster> I installed parse-edid and it looks correct reading /sys/device/omapdss/display0/edid.
<GrueMaster> I'm switching back to original kernel.
<rsalveti> ok
<rsalveti> could be a racing condition for some unknown reason
<GrueMaster> No problem with old kernel
<GrueMaster> And it was the only package I upgraded.
<rsalveti> try rebooting at least some 3 times, to see if it works every time
<rsalveti> and get the boot log too, if possible
<rsalveti> to compare
<GrueMaster> I did with the new kernel.
<GrueMaster> I'll have to mod the boot part to reenable the new kernel again.
<topfs2> rsalveti, if you have any questions regarding xbmc and I'm not here feel free to ping TheUni . I'll force him to idle here aswell ;)
<rsalveti> topfs2: np, thanks a lot
<TheUni> rsalveti: i do the business/consumer relations stuff for xbmc.. i've seen the blueprint and i'm quite interested. would love to have a chat.
<TheUni> if there's anything to chat about, that is :)
<rsalveti> :-)
<jo-erlend_> heh... On Ubuntu-devel today, there was an announcement of an IRC meeting regarding ARM... It sais Tuesday 2010-29-11 at 13:00 UTC. <-- Does that mean it has been held or that it will be held tomorrow?
<TheUni> rsalveti: out of curiosity, is Natty+1 the target?
<rsalveti> jo-erlend_: hehe, NCommander :-)
<rsalveti> it should be tomorrow
<jo-erlend_> rsalveti, NCommander? :)
<rsalveti> TheUni: we'd like to have a solution for natty
<rsalveti> jo-erlend_: he is the one who sent the announcement, probably
<TheUni> wow, ok
<jo-erlend_> oh, it's a nick. I get it. :)
<rsalveti> TheUni: but we're ok to change that for natty + 1
<TheUni> rsalveti: yea, for us to be an option, i'm afraid that's what it would have to be
<TheUni> though we should be in very good shape by then
<jo-erlend_> NCommander, it is quite impossible for me (or anyone else) to attend the ARM IRC meeting on Tuesday 2010-29-11 at 13:00 UTC. <-- Perhaps you could reschedule? :)
<rsalveti> TheUni: ok, we can probably push it to the repository, if it's not the default at least
<rsalveti> then for natty +1 that can change again
<TheUni> yea
<TheUni> we're working hard to target natty to get all the Ubuntu nits cleaned up
<GrueMaster> jo-erlend_: I believe persia is actively seeking a better time for the meeting.  You should also ping him.
<jo-erlend_> GrueMaster, well for me, any date that actually exists would be a better time. :)
<rsalveti> TheUni: got it, nice
<GrueMaster> jo-erlend_: Heh.  I see what you are referring to.  It is actually scheduled for 20101130.
<TheUni> rsalveti: so for Natty, we should be a good candidate for the repo, arm included. Then we could do focus on remaining needed changes for the default if interested
<rsalveti> TheUni: sure, that can work :-)
<GrueMaster> But we are looking to move it in the near future.
<TheUni> great
<NCommander> jo-erlend_: its being discussed int he meeting. I'm not very happy about that time myself, but its been that way for ages. The ARM meeting is what the Mobile meeting was (the name of the meeting was something of an artifact)
<TheUni> rsalveti: I'm subscribed to the blueprint (Cory Fields). Feel free to ping me. I'd like to make it a top priority for us, as it obviously would mean good things for us as well.
<jo-erlend_> NCommander, well. In your email, you said _Tuesday_ 29th. That's either today or tomorrow. Perhaps a new email would be in order, just to avoid confusion?
<NCommander> jo-erlend_: *groan*
<NCommander> I'll send a followup (its tomorrow in any case)
<rsalveti> TheUni: yeah, would be nice to have it working on arm nicely :-)
<TheUni> rsalveti: topfs2 can tell you more about the status. but we're currently working fine on beagle and a few other platforms, panda should be a much nicer target
<rsalveti> TheUni: yeah, that's what we're targeting
<TheUni> rsalveti: may i suggest a minimum/reference platform?
<rsalveti> TheUni: sure
<TheUni> ah, ok
<rsalveti> we're targeting panda because the hardware is nice, cheap, and we'll soon have the bamboo box around
<rsalveti> then panda can be easily used as a set-up box
<prpplague> rsalveti: hopefully around the 15th of jan
<TheUni> rsalveti: i mean.. i suggest that you specify your target/reference
<rsalveti> and can decode in full hd and etc
<TheUni> yup, same page then
<rsalveti> cool
<rsalveti> prpplague: nice :-)
<prpplague> rsalveti: i added a circuit on the ft2232 so you can have the ft2232 reset the pandaboard
<TheUni> rsalveti: problem we've had with arm is that it's such a segmented world. The main platforms we've seen so far have been beagle/tegra2/panda
<TheUni> beagle had cpu limitations, tegra2 was missing ion and involved intimate dealings with nvidia, panda seems real-world achievable. so we'll be using that as reference as well.
<jo-erlend_> IGEPv2 has been confirmed as working with the new kernel from linaro?
<TheUni> s/missing ion/missing neon/
<rsalveti> prpplague: nice
<rsalveti> TheUni: yeah, and panda is already around, working nicely with ubuntu
<jo-erlend_> I really like the pandaboard, except that it's too tall for me.
<TheUni> indeed
<jo-erlend_> I'm curious about the new marvell ARM server chips.
<topfs2> And I've compiled and run xbmc perfectly on panda
<topfs2> haven't tried any real resolution yet though but considering the GPU it should probably do 1080p
<topfs2> Atleast it would be possible to achieve in the near future
<topfs2> (our gui is rather hefty to render)
<prpplague> jo-erlend_: headers can easily be desoldered on the board
<prpplague> jo-erlend_: http://www.elinux.org/Panda_Bamboo
<topfs2> for a second there I thoght you had gone for bamboo for real
<tmzt_g2root> what is the 2d netbook package on maverick?
<tmzt_g2root> ubuntu-netbook and ubuntu-netbook-efl-default-settings ?
<jacquesdupontd> sorry i was testing my phone 3g unlimited tethering under ubuntu
#ubuntu-arm 2010-11-30
<Sp0tter> what is a good tablet for running ubuntu on?
<tmzt_g2root> what packages are needed for the efl version of netbook or unity in maverick?
<ndec> lool: hi. i don't understand your comment on #681267...
<hrw> bug 681267
<ubot2> Launchpad bug 681267 in debian (and 2 other projects) "Packages for armel are missing (affects: 1) (heat: 12)" [Unknown,New] https://launchpad.net/bugs/681267
<lool> ndec: Which part?
<ndec> lool: well, i don't understand what the problem is...
<ndec> lool: and what the fix is
<lool> ndec: https://code.launchpad.net/packages-arch-specific
<lool> ndec: We have some data files documenting which source packages are specific to some architectures, and in fact also which binary packages in some cases
<ndec> lool: so you mean that any packages that is arch specific (e.g. which is not Arch = any OR Arch = all) needs special attention?
<lool> ndec: It's even before that
<lool> ndec: Debian's wanna-build and Ubuntu's Launchpad schedulers simply don't schedule builds when a package is blacklisted according to this file
<ndec> lool: hey... one more new thing to learn today ;-)
<lool> This is useful in cases where the software is irrelevant for certain arches, or needs improbable porting
<ndec> lool: ok. so the problem was that cpuburn was blacklisted in this file. I see your latest commit where you add it... so now you need to submit the source package again, right?
<janimo> is grub2 too complex to be used on ARM boards instead of u-boot and others that are currently used?
<hrw> janimo: grub2 relies on first stage bootloader (bios, efi) when uboot is usually used as first stage one
<lool> ndec: https://launchpad.net/ubuntu/+source/cpuburn/1.4a-1build1
<lool> ndec: Yes, I had to wait some hours for new Pas to be picked up
<ndec> lool: thx!
<janimo> hrw: so grub2 would need to incorporate all the ARM specific hw bringup bits in order the fully replace them, ok
<antoche> hi folks
<antoche> I've made a Maverick microSD card for the beagleboard that kinda boots but not quite, is this the right place to ask for advice?
<persia> janimo, It's lower level than that: there isn't any code to *load* grub from anywhere by default (although I suppose one could wedge the code that loads other bootloaders to kinda work, but only sorta).  Compare to powerpc, where the boot process is openfirmware -> grub2
<persia> antoche, Yes.
<antoche> cool
<antoche> I roughly followed the instructions at http://elinux.org/BeagleBoardUbuntu#Maverick_10.10_2
<persia> janimo, We've discussed this to death, and while a grub2 port would always be nice, the consensus seemed to be that something like coreboot would be more worthwhile, although the vendors seem to want to stick with u-boot.
<antoche> and got a card that doesn't boot on power-up, although if I boot on the beagle demo card, stop the autoboot and then swap cards and run 'boot', it works
<hrw> persia: coreboot -> seabios -> grub2 or coreboot -> grub2 chain then?
<hrw> persia: coreboot is nice thing but iirc still x86 only
<persia> hrw, coreboot -> linux
<hrw> persia: you used coreboot at all?
<janimo> persia: thanks, is there a record of such discussions somewhere? I am mostly curious. Similar boot experience across all platforms would be nice to have
<persia> hrw, I heard someone demo'd something like it a few months ago at a conference.
<persia> janimo, There's a wealth of aging specs about it, but I think there's nothing coherent, sadly.
<janimo> ok
<persia> I very much agree, especially since we've been able to move to grub2 for everything else this cycle, but it really needs a first-stage bootloader.
<hrw> persia: I have machine with coreboot here. best way (to be able to update kernels) is coreboot -> (seabios ->) grub2 and kernel from disk
<persia> Someone could port openfirmware (it is known to work on ARM), or something, but most of the ARM folks seem to prefer having just one bootloader, rather than first-stage, second-stage (something about boot speed)
<hrw> persia: coreboot+linux can be made of course but each update == reflashing chip
<persia> hrw, That's the most conventional way, indeed :)  Apparently, doing something with kexec is somehow faster.
<janimo> yes, easier to bring up and test, especially if they only use a minimal BSP image over that and leave it to others to fill in
<persia> hrw, No, you use kexec(), so you can update the running kernel separately from the flash kernel.
<persia> antoche, We don't support that image: try https://wiki.ubuntu.com/ARM/Beagle
<hrw> persia: if kexec works properly
<persia> hrw, Well, of course :)
<antoche> persia: oh ok
<persia> antoche, rcn-ee is about sometimes, so you might get some support, but it's not an official means of creating images.
<antoche> persia: rcn-ee?
<antoche> sorry I'm quite new to all this arm business
<persia> The person who created the image at rcn-ee.net which is referenced in the wiki page you indicated you used :)
<antoche> arf ok sorry :)
<antoche> I yet have to know who's who here
<antoche> persia: I see the page you sent me says "running Ubuntu on a C series Beagleboard", any known problem with a beagle xM ?
<hrw> antoche: same image, same kernel
<persia> Did the oddity with xM sound get sorted?  I forget.
<antoche> persia: what was the oddity?
<persia> I think it was something about issues with sound on both HDMI and the audio jacks.
<antoche> hm ok
<persia> As long as you're not trying to do both at once, shouldn't be an issue, I think.
<hrw> persia: xM got hdmi audio?
<persia> hrw, Doesn't it?  I thought it had real HDMI, rather than just DVI-on-HDMI jack.  I may be mistaken.
<hrw> persia: <xM had dvi-on-hdmi. I never had xM so cant say
<persia> I'm just guessing based on memory of IRC traffic :)
<berco> ogra: I found my pb about alsa-utils I think
<berco> ogra: looks like updating alsa-utils in a ssh console will generate the errors I see. If I do the same thing in a console on the board, the installation goes fine.
<tmzt_g2root> is there anyway to install ubuntu-netbook without installing the xserver packages and everything else? possibly by seeding it?
<persia> tmzt_g2root, Not easily, because they are preinstalled images.  You might try the netinstall image, which ought give you infinite customisation.
<tmzt_g2root> I'm on a rootstock -s ubuntu-minimal
<tmzt_g2root> I'm trying to install only the efl launcher, I'm using another X server so I don't need xserver-*
<tmzt_g2root> but when I install ubuntu-netbook, even without recommends it wants to install all those packages
<persia> Ah, yeah, because it needs an X server, and it can't tell you have one.
<tmzt_g2root> is there a provides package I can use?
<persia> If you're installing non-packaged software, you probably want to look at the equivs package to fake it.  If you're using a packaged X server, there's a bug in the packaging.
<tmzt_g2root> I'm trying to build a chroot with a minimal foot print, the X server is outside the chroot
<persia> You could just install --no-recommends netbook-launcher-efl : the "ubuntu-netbook" package will always pull an X server (unless you fake it).
<tmzt_g2root> I did --no-recommends
<tmzt_g2root> it still installs xserver-*
<tmzt_g2root> I also tried with xserver-xfbdev
<tmzt_g2root> ubuntu-netbook depends on xorg
<tmzt_g2root> okay, so if this is just a virtual package, what actually provides the efl launcher? that's what I'm trying ot install
<persia> netbook-launcher-efl is the EFL launcher package.  ubuntu-netbook is just a metapacakge with everything.
<tmzt_g2root> yeah, I found it on so, I couldn't see why netbook-launcher-efl wasn't a dep, but I guess it's switched to unity now?
<persia> I didn't think there was an EFL implementation of unity.  Depends what you're trying to do, and with which release you're trying to do it.
<tmzt_g2root> it's not a release, it's just a maverick rootstock
<persia> For maverick, the EFL launcher was the netbook-launcher-efl package.
<tmzt_g2root> I'm trying to build an image for my X server on android to give users a simple usable demonstration possibly with multitouch eventually
<tmzt_g2root> right, so that's what I'm installing, thanks
<persia> You probably want some number of other packages from ubuntu-netbook, to give the equivalent experience.  I'd suggest installing them in small groups, so you can avoid installing stuff you don't want.
<tmzt_g2root> yeah, so I'm going to have to figure out how to use a virtual package, but for now I'll just have a script they can use (the alpha testers essentially) to install stuff
<szoszi> hello
<szoszi> is someone here who can help me? I'm running ubuntu 10.10 on beagleboard-xm
<szoszi> I have a kernel related question
<szoszi> noone?
<szoszi> anyone here with the abilty to help me in kernel related question? :)
<ogra_ac> !ask
<ubot2> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<hrw> in other words: Don't ask to ask but ask
<szoszi> sorry
<szoszi> so, I installed ubuntu 10.10 onto beaglebboard-xm, according to http://elinux.org/BeagleBoardUbuntu#Beagle_xM. Noticed that has heavy cpu loads, and found that "Demo Images contain a kernel with experimental options for the omap family... If you'd like to use ubuntu's supported kernel, just read "/etc/flash-kernel.conf" and disable the rcn-ee variable. Then install the ubuntu kernel and flash-kernel packages to overwrite. " Disabli
<ogra_ac> your paste ended at "flash-kernel packages to overwrite.  Disabl"
<szoszi> overwrite. " Disabling it will increase performance?
<szoszi> thats the ending
<ogra_ac> i guess you need to wait for rcn-ee to show up, he maintains these community images
<ogra_ac> (or use one of the official ones)
<hrw> or use linaro image
<szoszi> I see...
<rsalveti> don't know if kernel is your problem
<rsalveti> generally rcn-ee creates a very usable kernel
<szoszi> I do not no either, but they say if you want to use ubuntu's supported kernel
<szoszi> so in my reading it means that teir kernel is not fully supported
<ogra_ac> we are all working with the official images here
<ogra_ac> so you need to wait for the maintainer of the images you use for more info
<ogra_ac> he is on a US timezone so you will have to wait a while until he comes around
<persia> Hrm?  No reason one can't just install the regular packages.
<szoszi> okay...then an other question. I read /etc/flash-kernel.conf, #-ed out the mentioned line.  now how can I install ubuntu kernel? bit noob to linux...
<ogra_ac> persia, i have no idea how flash-kernel is modified on these images
<persia> `apt-get install --reinstall linux-image-2.6.35-22-omap flash-kernel` ought do it.
<ogra_ac> and i doubt anyone here has apart from rcn-ee
<persia> ogra, This is why one reinstalls it :)  I don't trust any out-of-archive sources or images.
<szoszi> persia, thats all?
<persia> Dunno.  Depends what else is non-standard from your install.  We all use https://wiki.ubuntu.com/ARM/Beagle as a guide
<ogra_ac> persia, thats lucid
<tmzt_g2root> persia: I'm having another problem, before when I did dbus-launch netbook-launcher-efl it would work, I could browse to different tabs and start programs, then I installed the preferences by symlinking them from xdg-une-efl and now no matter how I start the launcher it immediately fades and becomes unresponsive
<ogra_ac> https://wiki.ubuntu.com/ARM/OMAP is the right page
<persia> Um, shouldn't there just be one page?
 * persia is confused
<ogra_ac> the lucid pages should be aggregated under the OMAP one
<tmzt_g2root> okay, seems to be fixed after deleting .gconf
<ogra_ac> and https://wiki.ubuntu.com/ARM/Beagle shoudl go away (redirect to /OMAP)
<persia> There's too much content there to go away right now, but I agree :)
<ogra_ac> persia, the /OMAP page should generally become our landing page for all install instructions for all releases
<persia> ogra, makes sense: sort by installation target.
<ogra_ac> right
<ogra_ac> that was the idea behind the OMAP page
<ogra_ac> so we can ling it from cdimage and dont need to update cdimage index files for every release
<ogra_ac> *link
<tmzt_g2root> touch .Xauthority :) gksudo is so broken
<ogra_ac> ??
<tmzt_g2root> gksudo fails if it can't copy .Xauthority, but it doesn't check if there's anything in the file or if the host is in the acl
<ogra_ac> why would it not be able to copy it ?
<tmzt_g2root> because my Xserver isn't running inside the chroot
<ogra_ac> it definitely isnt broken in a default setup
<ogra_ac> ah, well
<ogra_ac> dont blame software for not coping with a broken setup ;)
<tmzt_g2root> right, but it's a false positive
<ogra_ac> there are certain steps you need to take to run X apps in chroots
<tmzt_g2root> it wasn't going to fail, but it gets out with an error messge
<ogra_ac> (like bind mounting the right dirs etc)
<tmzt_g2root> yeah, but I have make my server dump the .Xauthority somewhere first
<ogra_ac> there is debian documentation for such setups somewhere
<tmzt_g2root> or figure out how to generate the cookie, I'm not even quite sure how it works
<ogra_ac> yu bind mount /tmp and /home/$USER into your chroot, gdm creates the cookie at login time
<persia> These days you have to fiddle with /var/run for dbus also
<ogra_ac> yeah
<szoszi> reinstalled kernel
<szoszi> maybe slightly faster, but still could produce 1.3 cpu load...with just an apt-get update...
<tmzt_g2root> so netbook-launcher isn't intended for use with touchscreens?
<persia> szoszi, values > 1 for load are typical with apt-get update: it's multithreaded, so there is almost always something waiting for CPU time, unless you have really slow IO.
<persia> tmzt_g2root, I wouldn't say that: I'd say instead that testing on touchscreens has been light.
<tmzt_g2root> well, finger interaction with the scrollbar and scrolling with touch don't work, though my touchscreen is only sending normal mouse events
<tmzt_g2root> I don't know if that's why
<szoszi> persia, than that might be my problem? Mostly IO usese higher percentage of CPU...
<szoszi> like this : CPU usage 	0% user, 1% kernel, 42% IO, 57% idle
<persia> szoszi, Um, no.  IO typically uses no CPU, although the CPU may block waiting for IO to complete and be unable to do anything at all.
<persia> That means your CPU isn't doing much of anything, just waiting for the IO subsystem to provide some data.
<ogra_ac> IO uses CPU if your rootfs is on USb
<ogra_ac> due to the nature of USb
<szoszi> rootfs is on micro SD
<persia> ogra, Why?  Does all the USB accounting overhead get called "IO" by the kernel?
<ogra_ac> no idea, i just know that USB usually uses CPU time for transfers
<persia> Ah, yeah.  That's true (assuming you don't have a separate USB data transfer core in your hardware, with appropriate drivers).  I just didn't know it showed up as "iowait" in the linux accounting subsystem.
<szoszi> okay :) I'm confused. :) Will download and install official ubuntu image :D
<szoszi> https://wiki.ubuntu.com/ARM/BeagleNetbookInstall it's not mentioned here, but as I know a fat partition and u-boot is requered. From where can I obtain proper files for this?
<persia> szoszi, They are already included in the image.
<ogra_ac> wrong wikipage again
<ogra_ac> follow https://wiki.ubuntu.com/ARM/OMAP
<ogra_ac> we didnt support XM before maverick
<persia> Couldn't: it didn't exist.
<szoszi> so lucid wont run on xm?
<ogra_ac> right
<persia> Very unlikely.
<szoszi> shit...just felt that that netbook-look is quite handy :)
<persia> !ohmy > szoszi
<ubot2> szoszi, please see my private message
<persia> It's available in maverick as well :)
<szoszi> http://cdimage.ubuntu.com/ports/releases/maverick/release/ here is no premade image, as I see. Or you mean as a package?
<persia> See the URL in the /topic :)
<szoszi> : ubot2 how?
<ogra_ac> the maverick images look pretty much the same as the lucid ones
<ogra_ac> the UI is the same launcher
<szoszi> persia...right :)
<szoszi> thanks :)
<armin76> !ohmy
<ubot2> Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.
<armin76> :D
<rcn-ee> szoszi, saw your message on #beagle, swapping kernel's isn't going to really dramaticly improve your performance.. swapping out the card that came with your xM with a class 6 will give you a little more..
<ogra_ac> ugh, who still uses class 6 for rootfses ?
 * ogra_ac would always recommend class 10
<rcn-ee> well class 6+ i use usb/sata drives.. ;)
<ogra_ac> :)
<rcn-ee> but anything is faster then the sd card that comes with the xM...
 * ogra_ac didnt know the XM ships one
<ogra_ac> mine came without card
<rcn-ee> you had a pre-production one.. ;)  the production ones come with a default easy first boot angstrom.. never booted it myself..
<szoszi> rcn-ee, thanks for the tip, but average loads are still over 1. Maybe try angstrom next. :) But as you nor I did boot the factory image
<szoszi> but by the way I feel it slightly better ;)
<rcn-ee> you will get a slight speed bump from angstrom, as they run the xM at 1Ghz...  Mine is limted to 800.. for comparsion which io load command where you running?
<szoszi> rcn-ee, could you please ask "for comparsion which io load command where you running?" a diffent way? I cannot catch the question...
<rcn-ee> szoszi, sorry slow morning.. it wasn't top.. which command where you monitoring kernel and i/o %...
<szoszi> rcn-ee, just installed webmin...
<szoszi> maybe it's not trustable, I do not really know, but seems correct
<rcn-ee> ah, yeah use to run that on my beagle's that program seems to creates a lot of extra i/o itself..
<szoszi> so you blame webmin for lots of IO? where can I monitor IO? :) top does not show up
<hrw> use iotop?
<rcn-ee> iotop/iostat/etc..
<szoszi> hello again, downloaded and tried to write ubuntu netbook arm image, like this sudo sh -c 'zcat <imagename> /dev/sda, but atfer hitting enter I can only see a ">" and seems nothing happens. Any idea?
<GrueMaster> Yes, add a closing '
<szoszi> ...did not notice...I should se no charecters flowing randomly? and changing rapidly?
<ogra_ac> no, you see nothing until the command is done usually
<szoszi> then something is wrong
<ogra_ac> yes, you miss > in your command
<ogra_ac> sudo sh -c 'zcat /path/to/downloaded/image.img > /dev/sda'
<szoszi> now seems fine :)
<ogra_ac> :)
<szoszi> iotop shows disk write 10-20M :) Thanks ogra_ac and sorry
<ogra_ac> sorry ? for what ?
<ogra_ac> nothing to feel sorry about ;)
<szoszi> ogra_ac I should spend more time with linux and less with M$ products. But at the company we use M$
<ogra_ac> no need to excuse yourself for that
<persia> szoszi, Don't make it a "should": do what you enjoy.  Ensure you can afford to do so :)
<szoszi> persia, with my girlfriend we are planning to move to the uk :D There are non-it jobs at M&S for start. Later on migh pick IT angain
<rsalveti> ogra_ac: new qt package, that disables neon by default is not yet at natty
<rsalveti> then to properly get a package version for the ppa it would be good to have the same commit you did for natty
<szoszi> I messed up. Just noticed that I need a 4gb+ memory card for the image, but I have a 2 gb inserted, can I do anything with this premage image to fit?
<ogra_ac> rsalveti, so you need my upload first ?
<ogra_ac> ScottK, ^^^
<rsalveti> ogra_ac: it'd be good, because then I just build a new version with ppa1 on it
<ogra_ac> ScottK, i will upload qt with the same change i did in the SRU, rsalveti will provide a PPA with NEON
<ogra_ac> just FYI
<ScottK> ogra_ac: There's no point in uploading to Natty as it will just FTBFS.
<rsalveti> argh, true
<ogra_ac> (to be honest i would be ok if the maverick change would just be allowed into -updates and we leave natty as is and give upstram time to fix it during the cycle)
<rsalveti> it's still broken
<ScottK> ogra_ac: I'd prefer that.
<ogra_ac> lets go to -devel and convince pitti then
<rsalveti> alright
<szoszi> I messed up. Just noticed that I need a 4gb+ memory card for the image, but I have a 2 gb inserted, can I do anything with this premage image to fit to a 2gb sd card?
<ogra_ac> no
<szoszi> thought so :)
<ogra_ac> it is 2.2G big if it is unpacked
<ogra_ac> so you truncate it if you write it to a smaller card
<szoszi> lol, than I have to go and buy an sd card :)
<persia> Consider it an opportunity to get a fast one :)
<szoszi> :D
<szoszi> that will be the second :)
<szoszi> by the way the firs option faster than bigger :D
<szoszi> since I received my beagle I'm thinging, but could not find an example, is is possible, did someone manage to install multiple OS on a single sd?
<fluitfries> seems like the Toshiba Mini NB300 series is a decent netbook option for home/small business use?
<persia> Aside from the fact that it's the wrong architecture :)
<fluitfries> knew something would bite me in the ass...  just looking for basic netbook advice.  sorry.  :P
 * janimo finds the reason for NUX FTBFS
<ogra_ac> janimo, wohoo
<ogra_ac> great
<janimo> need t6o talk to NUX guys, I am not sure I can just upload a fix. Upstream is Canonical apparently
<janimo> strangely I see not NUX pacage on x86 natty but have one on kakadu
<ogra_ac> janimo, talk to didrocks on #ubuntu-devel
<janimo> ah ok. I tried ayatana
<ogra_ac> he maintains it in ubuntu and will incprporate fixes (and forward them to ayatana)
<janimo> ok. Went further anfd found another bug so still FTBFS
<ogra_ac> (and i knoe he planned an upload before A1)
<janimo> there's a release out a few hours ago
<ogra_ac> well, the last upload was 5 days ago
<janimo> uh, NUX is a graphics framework made for x86 win/lin/mac . Needs more work to learn about ARM, not a simple packaging FTBFS
<rsalveti> janimo: yeah, and needs to support gles to be fully compatible with arm boards
<janimo> I'll look at fixing the buld first. Is GLES a runtime or build req?
<rsalveti> janimo: probably something the dx team needs help with, if you have time
<janimo> sure, am looking at the code now
<rsalveti> janimo: gles is a nice to have, but we're ok if we don't have it as we can run gl with mesa by software
<janimo> may need to set up a bzr branch if there will be more than a few patches
<rsalveti> yeah, building on arm is the first step
<janimo> is gles hard? I am not familiar with its status, I see it is assgned to you
<rsalveti> janimo: are you familiar with gl and gles stuff? the idea of the bp is to move the packages to be gles by default
<rsalveti> on arm
<rsalveti> instead of gl
<rsalveti> then we can use the hw accelerated drivers
<rsalveti> like we have for omap3 and omap4 atm
<rsalveti> janimo: nux is required by the new unity + compiz stuff
<janimo> rsalveti: not familiar but have nothing against getting familiar
<rsalveti> :-)
<rsalveti> will be out for lunch now, we can talk more about it later :-)
<janimo> enjoy your meal!
<rsalveti> thanks :-)
 * rsalveti lunch
<tmzt_g2root> netbook isn't quite usable in wvga either
<ogra_ac> tmzt_g2root, nothing in ubuntu is optimized for 480px vertical, 600px is minimal
<tmzt_g2root> it's maximus, the open dialog was working without it and centered on the screen
<tmzt_g2root> but maximus thinks it's a top level and tries to expand it
<tmzt_g2root> theme looks totally out of place too
<ogra_ac> there are gconf keys for excluding apps from maximus handling
<ogra_ac> yeah, nobody made any effort to adjust to 800x480
<tmzt_g2root> yeah I need to put the gconf files back in there
<ogra_ac> well, persia did quite a while ago, but we didnt follow up on that
<tmzt_g2root> I lost my panels/window switcher too
<tmzt_g2root> is maximus a wm? can it be used to switch between programs? I can't seem to get anything to not be always on top
<tmzt_g2root> like it's unmanaged
<ogra_ac> maximus is a metacity extension iirc
<tmzt_g2root> so metacity is running?
<tmzt_g2root> or should be
<ogra_ac> i think so, not sure
<tmzt_g2root> doesn't seem to be running, that might be the problem
<prpplague> ogra_ac: bamboo pcb are out for production
<ogra_ac> wohooo !
<prpplague> ogra_ac: i have a couple other boards i'm looking at doing
<prpplague> ogra_ac: thoughts on a board the exact same size of the pandaboard that has the following: two usb host ports, eeprom, battery backed rtc, and some breakout headers
<ogra_ac> sounds like beagle Cx revived
 * armin76 points prpplague to #pandaboard
<ogra_ac> prpplague, no tower ?
<ogra_ac> (and no NIC)
<prpplague> armin76: ??
<mellis> hey i just set up ubuntu 10.10 desktop has anyone else made a image of that for download?
<ogra_ac> he just wants to tease you
<prpplague> ahh
<prpplague> ogra_ac: sorry what i meant was an accessory board for the pandaboard
<ogra_ac> mellis, the netbook images we provide contain dektop
<prpplague> ogra: basically just adds the extra ports
<ogra_ac> ah
<ogra_ac> i thought instead of what the panda has atm
<prpplague> ogra: it would be a inexpensive add on
<ogra_ac> additional USB ports would be good, yeah
<ogra_ac> since the two on the board are usually taken by kbd and mouse
<ogra_ac> and pattery backed rtc would be good too
<tmzt_g2root> anything with ethernet?
<ogra_ac> panda has ethernet already
<ogra_ac> as well as wlan
<tmzt_g2root> cool
<prpplague> ogra_ac: techincally all you need to add the additional usb ports is just to get some of these - http://www.amazon.com/2-Port-Rear-Panel-Bracket-Adapter/dp/B002IWEDSS
<ogra_ac> yeah, i know
<ogra_ac> but the board itself has only two which gets in your way if you want to run it as a desktop with usb disk
<mellis> ogra_ac yeah but thats the netbook desktop witch not what all useres what
<ogra_ac> mellis, no, the normal desktop
<ogra_ac> you can select it at the login manager
<ogra_ac> its shipped by default
<mellis> ahh ok i couldint get that image to work for me
<ogra_ac> on what hw ?
<mellis> beagle xm rev 2
<ogra_ac> should work
<mellis> it wouldint output to s-video
<ogra_ac> oh, s-video
<ogra_ac> yeah
<ogra_ac> not much tested by us
 * ogra_ac knows your bug i think
<mellis> yeah bit anoying
<ogra_ac> we'll try to put some focus on it in natty
<mellis> yeah that would be great
<mellis> even the u-boot in that image didnt output to s-video
<prpplague> ogra_ac: yea but you can add the extra ports pretty quick, the pinout is 1 to 1 for the connectors
<prpplague> ogra_ac: all you have to do is solder on the header
<ogra_ac> mellis, u-boot doesnt output to *any* graphical display
<ogra_ac> only to serial
<ogra_ac> prpplague, yup or use a proper plug
<mellis> the one i use outputs bars to s-video
<prpplague> ogra_ac: actually u-boot does have support for boot splash screen on some devices
<ogra_ac> prpplague, i know
<ogra_ac> i was talking about ubuntus u-boot binary indeed
<prpplague> ahh
 * prpplague needs to get that working for the panda
<ogra_ac> sakoman cant help with that ?
<ogra_ac> we are using linaros u-boot with should be his
<prpplague> ogra_ac: yea i am sure he can for a fee , hehe
<ogra_ac> heh
<ogra_ac> well, thats good, we need to keep him alive ;)
 * ogra_ac is all for paying good developers money ;)
<ogra_ac> GrueMaster, my omap4 buld is running since more than 30mins already, seems it will survive, so you should have something to test in about 1-1.5h
<GrueMaster> ok
<Kamondelious> anyone know how to fix "unable to enumerate USB device on port" errors?
<Kamondelious> I'm running a BeagleBoard Rev C3 with 10.10
<ogra_ac> Kamondelious, are you using a powered hub ?
<Kamondelious> yes
<ogra_ac> well, C3 did have USB issues iirc
<Kamondelious> I only seem to have issues with this error when I plug in my webcam
<Kamondelious> dang
<ogra_ac> oh, that rather sounds liek a missing driver
<ogra_ac> what kind of webcam is that ?
<Kamondelious> uvc
<ogra_ac> hmm, should have a driver iirc
<Kamondelious> the uvc module is loaded
<Kamondelious> and the camera works on other computers
<ogra_ac> weird
<ogra_ac> it did get autmatically loaded ?
<ogra_ac> when plugging in the camera ?
<Kamondelious> no, I loaded it with modprobe
<ogra_ac> ah
<Kamondelious> added it to /etc/modules
<ogra_ac> well, that wont help much
<ogra_ac> udev should load it automatically if your cam is associated with the driver
<Kamondelious> ahh
<Kamondelious> ogra_ac, I can confirm that I have had this same camera working on my BeagleBoard before, with a previous Ubuntu (10.04 community) install
<Kamondelious> very odd, I might have to break down a buy another powered usb hub to eliminate that as the issue
<berco-mac> GrueMaster: hi
<berco-mac> GrueMaster: I was wondering if you saw my update on Launchpad and if you were unblock with your display
<GrueMaster> I saw the LP entry.  Haven't gotten further yet.
<berco-mac> I had my colleague do the exact same update and we couldn't see the issue. that's weird. I need to compare our setups
<epp> hey guys i just picked up a tablet that runs android and has ubuntu running ARM. What are the repos for ubuntu arm?
<epp> all they have is some crap one that has almost no software
<rsalveti> epp: what is your tablet?
<rsalveti> we first need to check if it's compatible with ubuntu
<rsalveti> like what arm cpu and etc
<epp> rsalveti, its running ubuntu
<rsalveti> epp: oh, if you got it running already you're fine :-)
<epp> rsalveti, smart Q7
<epp> it came preloaded but its slimmed down
<rsalveti> epp: with which ubuntu version?
<epp> rsalveti, im not sure
<rsalveti> lsb_release -a usually tells you
<epp> okej
<epp> hold
<rsalveti> or look at /etc/issue and/or /etc/issue.net, you can at least have a clue if they generated it fine
<epp> okey
<epp> i finally got sshd working
<epp> ubuntu 9.10
<rsalveti> epp: ok, this is the karmic release
<epp> rsalveti, i just need some repo address
<rsalveti> epp: http://ports.ubuntu.com/ubuntu-ports
<rsalveti> deb http://ports.ubuntu.com/ubuntu-ports karmic main
<rsalveti> will probably do the work
<epp> ok but dont i need to add arm specific or does it detect?
<rsalveti> epp: nops, just this line should be enough
<epp> cool
<epp> god it doesnt even have nano i dont know vi haha
<rsalveti> you can use echo, cat hehe
<epp> ahh perfect ill echo >
<epp> whats append to file >> or >
<epp> its >>
<berco-mac> epp:  yes
<epp> great looks like its working
<epp> this is the original haha
<epp> deb http://ubuntu.srt.cn/ubuntu-ports/ karmic main universe restricted multiverse
#ubuntu-arm 2010-12-01
<henry1> Where can I get a binary Linaro toolchain so that I can put it anywhere I want?
<GrueMaster> Check on #linaro.  Someone there would know.
<GrueMaster> Grrr.  A1 is a fail at this point.  Kernel oops on second boot, shortly after mounting rootfs.  http://paste.ubuntu.com/538505/
<GrueMaster> ogra: rsalveti:  ^^^
<hrw> morning
<sveinse> Hi guys. This is perhaps OT here, but I tried to cross compile Qt using the g++-arm-linux-gnueabi compiler from Maverick. The compilation failed, while the CodeSourcery gcc don't. The failure is "selected processor does not support Thumb mode `swp r4,r3,[r2]'". The compile options are set to "-march=armv7-a -mtune=cortex-a8 -mfloat-abi=softfp -mfpu=neon". I notice the CSL gcc is 4.4.1, while...
<sveinse> ...the Ubuntu gcc is 4.5.1.  Does this ring any bells to anyone?
<rsalveti> hrw: ^
<hrw> sveinse: can you report bug against gcc-4.5 and give me number?
<sveinse> hrw: In whos bug system? Gcc or ubutu?
<hrw> ubuntu
<sveinse> hrw: I could try recompiling using the 4.4 version to see if its related to some difference between the CSL and Ubuntu or if its related to 4.4. vs 4.5
<dcordes> tmzt_g2root: regarding the custom netbook-launcher-efl session
<tmzt_g2root> yes
<tmzt_g2root> rsalveti: maybe #linaro ?
<dcordes> tmzt_g2root: I found descriptions on how to build a custom session in some ubuntu wiki. I was searching for how to customize the gnome panel as it is locked
<dcordes> tmzt_g2root: the problems I see with netbook on small screen touchscreen devices are only few
<tmzt_g2root> dcordes: the instructions didn't work for me, the gconf stuff didn't change anything
<tmzt_g2root> yeah, it's pretty nice. installing packagekit fixed software-center
<tmzt_g2root> it's a bit off the screen but mostly usable
<ogra_ac_> tmzt_g2root, hrw is in both channels luckily (#linaro and here) ;)
<dcordes> tmzt_g2root: 1) off-screen areas in some programs (related to maximus) 2) small buttons, scroll bars, etc => problems navigating
<tmzt_g2root> dcordes: let's work on here https://github.com/tmzt/native-netbook we should be able to share everything between hd2 and androix on wvga ws
<ogra_ac_> dcordes, to change the locked gnome-panel properly you would have to change and rebuild ubuntu-netbook-efl-default-settings
<dcordes> tmzt_g2root: that would be nice. but to keep in touch with upstream we should document our work in launchpad
<ogra_ac_> all panel settings we do there are mandatory
<tmzt_g2root> dcordes: right, I'm just trying to collect scripts and stuff and then when I'm ready to do a package like ogra says I can just migrate that stuff
<tmzt_g2root> we can put in on a ppa too, but I don't know if you have to be a developer for that
<tmzt_g2root> can't put raw scripts on ppa though
<ogra_ac_> currently you have to for armel only packages
<ogra_ac_> ubuntu-netbook-efl-default-settings is arch all though
<ogra_ac_> so for that package any ppa will do
<dcordes> tmzt_g2root: ... forgot an important point 3) on screen keyboard not available everywhere
<tmzt_g2root> ogra_ac_: it will probably require changing launcher itself, we need kinetic scrolling and mtdev (finger width) support
<tmzt_g2root> dcordes: that might be an issue, it isn't for me with g2 though, but please solve it
<tmzt_g2root> I'm trying to get androix to send some events for soft keys on android
<ogra_ac_> tmzt_g2root, well, then you have to wait until our armel PPA spec is implemented
<tmzt_g2root> I haven't decided how to handle them yet thouh
<ogra_ac_> which wont happen before the alpha2 release i suspect
<tmzt_g2root> ogra_ac_: okay, I'm putting together a repo on androix.org for now
<ogra_ac_> but it will enable armel on all PPAs
<tmzt_g2root> that would be good, especially if it could build for older architectures, but I don't expect that
<ogra_ac> it will use the ubuntu defaults
<dcordes> tmzt_g2root: regarding on screen keyboard lack 3) https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/626055
<ubot2> Launchpad bug 626055 in ubiquity (Ubuntu) "oem-config: make on-screen keyboard available (affects: 1) (heat: 40)" [Low,New]
<tmzt_g2root> maybe we could do a small panel thing that just does indicators, no clue if they would work with efl though
<tmzt_g2root> we could mix in illume and gnome, that would be confusing
<ogra_ac> have a look at ubiquity
<ogra_ac> it brings a minimal panel in maverick
<ogra_ac> i guess its not hard to rip the panel code out of it and build a standalone package
<tmzt_g2root> ogra_ac: I need to ask you about remixes and policies, I'm trying to build something to run Ubuntu on top of Android, for now I'm calling it Native Netbook
<tmzt_g2root> yeah, uquity works on 2d?
<ogra_ac> sure
<tmzt_g2root> cool, we'll look at that then
<ogra_ac> tmzt_g2root, mail trademarks@ubuntu.com, i dont know the exact policy
<dcordes> tmzt_g2root: small panel ? can you elaborate ?
<tmzt_g2root> dcordes: how do you find this stuff in lp?
<ogra_ac> might be that you cant use the logos etc
<dcordes> tmzt_g2root: I enter my lp URI :)
<ogra_ac> http://www.ubuntu.com/aboutus/trademarkpolicy
<tmzt_g2root> dcordes: I'm going to let you handle keyboard stuff :) but I'm sure I'll need it when people with nexus, etc. want to try it
<dcordes> tmzt_g2root: I don't have any android device, sorry.
<tmzt_g2root> dcordes: right, it's not an android issue though, it's a touchscreen issue
<tmzt_g2root> and you do have a leo
<tmzt_g2root> I would be using an osk in X, not androids
<dcordes> I am using onboard , the standard ubuntu osk
<tmzt_g2root> can't IME do what your bug 443986 says, pop up osk if the widget gets keyboard focus?
<ubot2> Launchpad bug 443986 in onboard "RFE: Add option to automatically show and hide onboard (affects: 5) (dups: 1) (heat: 18)" [Undecided,New] https://launchpad.net/bugs/443986
<tmzt_g2root> I guess X really needs a flag to tell it if a physical keyboard is attaeched, or you would have to enumerate the Xi2 device list
<dcordes> tmzt_g2root: that would be nice
<dcordes> tmzt_g2root: what is IME ?
<tmzt_g2root> input methods
<tmzt_g2root> it would require a gtk/gdk patch too I assume
<tmzt_g2root> but at least there's a standard way to handle that
<dcordes> can you append it in the bug ?
<tmzt_g2root> it's also possible openmoko had this on the gtk version a few versions back
<tmzt_g2root> and figure out oauth again? :)
<dcordes> currently openmokoe shr uses some efl osk keyboard
<tmzt_g2root> how do you add a project or distribution?
<tmzt_g2root> currently, I'm talking about the gtk version they had
<tmzt_g2root> they also had the finger gtk theme
<dcordes> right I remember
<tmzt_g2root> I've ping #xorg-devel about the Xi question
<tmzt_g2root> dcordes: have you tried getting any of the new 3d stuff to compile against bionic so it can use libgles_cm?
<dcordes> many touchscreen device owners would love such a feature in Xorg
<dcordes> I have no clue about all the 3d stuff
<tmzt_g2root> it's one properties, PhysicalKeyboard or whatever
<tmzt_g2root> that's why I'm sticking with efl at the moment
<tmzt_g2root> dcordes: https://wiki.kubuntu.org/X/Blueprints/Touchscreen/UDS-M
<tmzt_g2root>  that's not kubuntu specific, they just show up higher in google
<tmzt_g2root> ogra_ac: what happened to the mobile channel? where did all the netbook stuff get moved too?
<dcordes> tmzt_g2root: ok. we might as well discuss TS things in #ubuntu-touch
<tmzt_g2root> I should just see if starting metacity fixes it, I don't think maximus is supposed to work standalone
<tmzt_g2root> if you have a working panel config I can help you push it to my git or whatever you have
<dcordes> tmzt_g2root: in launchpad we might create a 'project' 'ubuntu on small screen (& touch screen devices)'
<dcordes> tmzt_g2root: then we can have bugs like off screen windows, lack of osk affect it
<tmzt_g2root> WVGA Touchscreen ?
<dcordes> that would exclude vga devices and exotic resolutions
<tmzt_g2root> like qvga?
<tmzt_g2root> you need this for your kaiser :) ?
<tmzt_g2root> WVGA is a difficult case, most of the bugs will be height related and also apply to VGA
<dcordes> QVGA screens are too small for any of this and the devices' other hw is too slow to run full ubuntu systems
<hrw> in basement I have XGA 10" touchscreen device
<dcordes> I think small screen is good. but what about the approach ?
<dcordes> in general means
<tmzt_g2root> define small
<dcordes> ok max wvga
<tmzt_g2root> this isn't for XGA or WXGA or 1024x600 there's plenty of coverage for that
<dcordes> ah true
<dcordes> didn't think of that
<dcordes> we can do smartphone & pda then ?
<dcordes> it would cover phone functionalities
<ogra_ac> tmzt_g2root, netbook (unity) is fully handled by the desktop team now (since unity merges both desktops)
<tmzt_g2root> wvga+ like the motorola's I would say, but that's waht 854x496 or so
<tmzt_g2root> ogra_ac: is 2d/framebuffer still supported?
<ogra_ac> not atm
<ogra_ac> only with a std desktop as fallback
<tmzt_g2root> ogra_ac: I don't have 3d support yet, I should be able to get 3d working but it might just be redirected rendering/AIGLX stuff
<dcordes> tmzt_g2root: know what let's just go device specific (ubuntu on hd2 & g2) if others want to hop on we can generalize later
<ogra_ac> depends on your platform, there is no GLES support in unity yet
<tmzt_g2root> ogra_ac: so I'm starting with netbook-efl, most of these problems will be unrelated to the acutal desktop, bugs in programs etc.
<tmzt_g2root> ogra_ac: well, it's going to have to be GLES, so that's another reason to stick with 2d for now
<tmzt_g2root> dcordes: G2 won't have keyboard issues, the things we have in common are WVGA and Touchscreen
<dcordes> tmzt_g2root: ok I don't see a problem there
<ogra_ac> just note that we might stop using the efl launcher in ubuntu (so support will rather have to be community based)
<tmzt_g2root> ogra_ac: yeah, it will still be in natty or that's not known yet
<ogra_ac> we wont remove the package from the archive
<ogra_ac> but given that it will likely not be used by default anymore bugfixes and maintenance has to come from the community
<tmzt_g2root> I think the only thing we need to change in it is the scrolling issue for touchscreens
<tmzt_g2root> yeah, okay
<tmzt_g2root> does it have a maintainer or we need ubuntu developer for that? (not canoncial)
<dcordes> tmzt_g2root: how about "smallscreentouchscreen" project
<ogra_ac> well, you can indeed work through a sponsor
<ogra_ac> but for uploading to ubuntu you will need one
<tmzt_g2root> what is the project for? just tracking bugs against ubuntu that affect screenscreen touchscreens? I really think small is too vague
<dcordes> yes to track bugs that affect our devices
<tmzt_g2root> as far as aspect, we really aren't going to support vga either because that would require massive chnages from what every laptop/netbook is now
<dcordes> and maybe to upload non-sub-project-specific scripts/code later
<tmzt_g2root> well, the packages, but those are all config stuff, I wouldn't be putting any system stuff there at all
<dcordes> yes config etc
<tmzt_g2root> I mean like launcher defaults, maybe unity places stuff if we can switch to unity
 * ogra_ac is off for a while
<dcordes> tmzt_g2root: smartphonebuntu ? I think it is not neccessary for the project name to refelct the exact aims
<tmzt_g2root> no, read the trademark policy
<tmzt_g2root> which ogra linked to
<dcordes> argh
<dcordes> smartphone-remix
<tmzt_g2root> possibly
<dcordes> you like it? any other idea ?
<tmzt_g2root> it
<tmzt_g2root> I'm looking for developer to create new on-screen keyboard with Input Method Editor. Similar to those available on mobile devices. Currently I'm using matchbox-keyboard but for my purpose I guess it's worth start from scratch.
<tmzt_g2root> oops
<tmzt_g2root> it seems to be what I'm trying to do
<dcordes> tmzt_g2root: https://launchpad.net/smartphone
<tmzt_g2root> can you duplicate the ~lg bugs there?
<tmzt_g2root> link them
<ogra_ac> GrueMaster, where is the bug for that and does cooloney already know (and work on it) ?
<dcordes> tmzt_g2root: I did already. check https://bugs.launchpad.net/smartphone
<tmzt_g2root> dcordes: I discussed the xinput problem, I think I can just add a property to the device by patching evdev, or in my case, in the server init
<tmzt_g2root> so it would show up when you do xinput list-props <id>
<tmzt_g2root> there's already a "Device Enabled" property
<dcordes> tmzt_g2root: to which device ?
<tmzt_g2root> then the IME just has to walk that and see if any are Physical && Enabled, and if so, not show the osk
<tmzt_g2root> to the keyboard device
<dcordes> ok
<tmzt_g2root> then we patch evdev to handle the SW event that's created when you slide the keyboard
<tmzt_g2root> for you, when you plug your usb keyboard the same thing happens
<tmzt_g2root> and for me, I get the value from android and set the priv myself
<dcordes> is this a global keyboard presence detection mechanism ?
<tmzt_g2root> yeah
<dcordes> patching evdev - is this specific to the device (driver) ?
<tmzt_g2root> but onscreen keyboards and x2x won't register that property
<tmzt_g2root> no, evdev already detects if it it's a keyboard, it will be wrong for uinput keyboards so we may have to put it in udev or something else
<tmzt_g2root> like hal did, but it didn't propogate it
<dcordes> are there evdev / Xorg bugtrackers ?
<tmzt_g2root> there are, but I'll propose it to the list later, we can just put it on my github for now
<dcordes> youz should publish the approach and gather interested people's attention
<tmzt_g2root> I already have half of xorg cloned
<dcordes> ok bugtracker is nice
 * ogra_ac would recommend asking in #ubuntu-x
<tmzt_g2root> ogra_ac: is that supposed to be public? I was having an issue with it
<ogra_ac> sure thats public
<tmzt_g2root> never mind
<tmzt_g2root> weird
<dcordes> ogra_ac: as tmzt_g2root's approach sounds to me it will be better to have it a global X thing and not discuss it distro internal
<ogra_ac> sure
<tmzt_g2root> ogra_ac: I pinged daniels in #xorg-devel he agreed with the property thing, and reminded me of Device Enabled
<dcordes> then again there might be many ubuntu developers interested in supporting it
<ogra_ac> still you should talk to the ubuntu X force
<tmzt_g2root> I'm sure acpi devices already have something like that
<tmzt_g2root> right
<tmzt_g2root> touchpads I mean
<dcordes> ogra_ac: soon as it is on Xorg list we should refer to it there
<dcordes> I have to run catch you guys around
<ogra> sigh
<ogra> so i think the kernel panic on boot is run-init failing
<ogra>  /init: exec: line 331: run-init: Unknown error 17718852
 * ogra wonders if that toolchain related
<ogra> GrueMaster, rsalveti, bug 683683
<ubot2> Launchpad bug 683683 in klibc (Ubuntu) "run-init on omap4 in natty dies with "run-init: Unknown error 17718852" (affects: 1) (heat: 8)" [High,New] https://launchpad.net/bugs/683683
<ogra> NCommander, so apparently klibc wasnt rebuilt yet in natty
<ogra> GrueMaster, btw, the error is easily visible if you dont tinker with serial consoles, it gets clearly printed on the screen
<RobotGuy> We are basing our PickleJar Linux on Ubuntu Maverick. :D
<RobotGuy> PickleJar Linux is the distro for our Pico Node project.
<ogra> RobotGuy, great to hear
<RobotGuy> We have an expansion board for BeagleBoard-xM in the design process now and hope to have the first few boards soon. Find out more at http://www.picklejar.org
<RobotGuy> Our kernel version is 2.6.35.4
<ogra> hrm, run-init is 93 LOC ... of which 40 are license text
 * ogra doesnt see what could be wrong in there
<NCommander> ogra: so no changes rebuild needed maybe?
<ogra> not sure
<ogra> look at the code, probably you see something obvious
<ogra> i surely dont
<ogra> hmm runinitlib.c seems to define some glibc stuff at the top
<NCommander> ogra: something is going hidiously wrongin run_init()
<ogra> why would it ?
<ogra> it didnt change
<NCommander> ogra: I'm saying that's what happening, I don't know why, but the error message being printed out suggests that's where we are blowing up
<ogra> well, but take a look at the code, probably you see something i dont
<NCommander>         /* If run_init returns, something went wrong */
<NCommander>         fprintf(stderr, "%s: %s: %s\n", program, error, strerror(errno));
<ogra> no, we are blowing up in line 88 already
<ogra> in run_init(realroot, console, init, initargs);
<ogra> which seems to come from runinitlib.c
<ogra> through run-init.h
<NCommander> right, run_init() is returning when it shouldn't e
<ogra> yes
<NCommander> the execv() call is failing
<NCommander> only place it can fail in this code and return a string of "Unknown error" I think
<ogra> well, it could fail because it gets wrong args
<ogra> and the linaro bug says the errno is random
<ogra> so nothing to grab
<NCommander> which linaro bug?
<ogra> did you read my bug ?
<NCommander> yeah, I did
<NCommander> I don't see anything from linaro
<NCommander> oh
<ogra> reload ?
<ogra> :)
 * NCommander just hit refresh
<ogra> oh, i did too
<ogra> there is a debian bug linked
<NCommander> Debug #334917
<NCommander> er
<NCommander> Debian bug #334917
<ubot2> Debian bug 334917 in klibc "klibc barfs on m68k syscall interface" [Important,Open] http://bugs.debian.org/334917
<NCommander> nice bug title
<RobotGuy> Debug seems appropriate, somehow. :D :D
<NCommander> ogra: looking at the debian bug, I think its unrelated simply because execve is a syscall and the first one is called directly. the ARM EABI syscall interface in klibc is correct else this would have blown up ages ago. So similar error, but I think unrelated causes
<GrueMaster> ogra: Ok I'm semi-awake.  What do you mean:  <ogra> GrueMaster, btw, the error is easily visible if you dont tinker with serial consoles, it gets clearly printed on the screen
<GrueMaster> It is not clearly visible on my screen.
<ogra> GrueMaster, you could have found it with the image from the 19th if you hadnt set up a serial console and just dropped splash from cmdline
<ogra> thats how i got it at least
<ogra> it shows up right before the kernel panic (which it does because there is no rootfs)
<NCommander> ogra: I'm looking at the linaro branch right now to see if anything is clear from that
<ogra> branch ?
<ogra> do they have a separate klibc branch from ubuntu ?
<GrueMaster> So then why doesn't it show up with serial console?
<GrueMaster> That doesn't make sense.
<NCommander> ogra: they said in their bug that they have a branch to fix it
<ogra> NCommander, yes, for the linaro build tools issue that shows up too
<ogra> NCommander, (OSError: [Errno 2] No such file or directory from remove_binary_dir.py from _run_code from _run_module_as_main).
<ogra> not related to to booting
 * ogra reboots with break=bottom
<ogra> lets take a look at the environment
<ogra> ok
<ogra> exec run-init /root /sbin/init gets me the same error
<NCommander> ogra: any chance you can get gdbserver into the initramfs environment?
 * NCommander finally got enough coffee into his bloodstream to be lucid enough to think
<ogra> try it ?
<NCommander> ogra: your ahead of me on having things to test on :-). I'm still reading emails while drinking GrueBrew Coffee
<ogra> i dont have any things to test on
<ogra> i just added break=bottom to my cdmline
<ogra> you need to write a hook and rebuild the initrd for getting your gdbserver included
<ogra> or for getting any other debug tool
<NCommander> ogra: just copy it in somehow, its not that difficult
<NCommander> but I'll get on it
<ogra> ??
<ogra> "copy it in somehow" ?
<NCommander> ogra: gdbserver is a tiny little stub binary
<NCommander> then attach to it with a cross-debugger
<ogra> you still need to re-roll the initrd
<ogra> so init=/bin/bash doesnt work either
 * ogra drops all bootarchs apart from root=
<ogra> argh
<ogra> bad idea ...
 * ogra beats jasper over the head
<GrueMaster> So it's a jasper issue?  I'm still reading emails and backscrolls.
<mellis> hey any idea how to get sound working on the beagle xm rev b
<GrueMaster> there is a rev b?  sigh.
<mellis> yeah :(
<armin76> lol
<mellis> i dont think they fixed anything really
<GrueMaster> no, but it is possible that something changed requiring an updated kernel...again.
<GrueMaster> Are you running the stock maverick release image?
<ogra> GrueMaster, ??
<ogra> its a klibc issue
<ogra> nothing to do with jasper
<GrueMaster> and I am not talking to you atm ogra.  Read the current thread.
<GrueMaster> mellis: ???
<mellis> sorry just went to get food
<mellis> yeah i got the minimal image and installed ubuntu-desktop package over it
<GrueMaster> no problem.
<GrueMaster> minimal image?
<mellis> also called the demo image
<mellis> i couldint get s-video to work on the preinstalled image
<davidm> prpplague, have a look at: http://dmtechtalk.wordpress.com/2010/12/01/progress-on-an-arm-cluster-server-box/
<mellis> yeah i got the demo image then installed ubuntu-desktop and the omap driveres on top
<davidm> prpplague, it will fit nicely into a standard 19" rack cabinet
<GrueMaster> If this image is attached to the ubuntu repositories, try enabling maverick-proposed and updating.  I think there was a fix for audio in alsa-utils, but it may be only omap4 specific.
<mellis> ok i will try
 * prpplague looks
<prpplague> davidm: right, i'm actually doing some with them on that
<mellis> humm my webcam also wont work so could it be a kernal problem?
<hrw> mellis: does it work with x86 box?
<mellis> the webcam yes
<sveinse> hrw: I confirm problems cross compiling Qt for both gcc 4.4 and 4.5, so its related to some difference between the ubuntu cross compiler and the CSL. I'll file a bug.
<mellis> and i cant find anything missing from my setup
<hrw> sveinse: mention package versions for gcc 4.4/4.5 and version of Qt. if Qt is from nokia then give url please
 * hrw -> out
<ogra> hmm, that dist-upgrade of my chroot will take a while
<rsalveti> GrueMaster: lmbench has the wrong bin path, if you noticed
<rsalveti> currently the package delivers armv5tel-linux-gnu instead of armv7l-linux-gnu
<rsalveti> that's because the package path is decided during build time, and detected by a script during runtime
<GrueMaster> hadn't gotten that far yet.  Any suggestions?
<rsalveti> and this package was built in an armv5 machine, while in karmic hehe :-)
<rsalveti> copying the files should be enough, but I also recreated the package, let me post you the link
<tmzt_g2root> dcordes: how do you switch the default gnome-session back to GNOME ?
<tmzt_g2root> without using gdm
<ogra_ac> tmzt_g2root, /usr/lib/gdm/gdm-set-default-session
<tmzt_g2root> as the user?
<tmzt_g2root> I don't seem to have that
<tmzt_g2root> oh, I'm not using gdm at all
<ogra_ac> no, its system wide, not as a user
<tmzt_g2root> just starting ck-session-launch dbus-launch --exit-with-session gnome-session
<tmzt_g2root> right, but I'm not getting a panel following these instructions
<tmzt_g2root> https://help.ubuntu.com/community/UbuntuNetbookEdition/ConvertGnomeSession
<rsalveti> GrueMaster: http://people.canonical.com/~rsalveti/lmbench/ for now
<GrueMaster> ok
<rsalveti> we should have a bug, will see if we got it already otherwise need to fill it
<mellis> hey i just installed the omap kernal package how do i get it to boot
<dcordes> tmzt_g2root: that is the wiki page I was talking about !
<tmzt_g2root> dcordes: I know, I saw it yesterday, but it doesn't work for me
<tmzt_g2root> /apps/maximus/exclude_class [Empathy,Totem,Gwibber,Gnome-language-selector,Gtk-recordMyDesktop,Onboard,Vlc,Seahorse-agent,Gnome-keyring-prompt]
<dcordes> tmzt_g2root: there was some error in the 2d instruction part
<tmzt_g2root> I'll have to add dialog or something to that, or just gedit's or libgtk open
<dcordes> tmzt_g2root: do you want me to look up anything in my rootfs ?
<tmzt_g2root> what script do you use to start the gnome-session?
<dcordes> sudo ln -s /etc/xdg/xdg-une/autostart/maximus-autostart.desktop /etc/xdg/autostart/
<dcordes> sudo ln -s /etc/xdg/xdg-une-efl/autostart/netbook-launcher-efl.desktop /etc/xdg/autostart/
<tmzt_g2root> I have both of those, I don't get a panel when starting gnome-session
<tmzt_g2root> the first time I started gnome-session it was a normal desktop, before symlinking that stuff
<dcordes> the first line.. I think it should be
<dcordes> /etc/xdg/xdg-une-efl/autostart/netbook-launcher-efl.desktop /etc/xdg/autostart/
<tmzt_g2root> /desktop/gnome/session/required_components/windowmanager mutter
<tmzt_g2root> /desktop/gnome/session/required_components/panel ''
<tmzt_g2root> oh
<dcordes> can you try that ?
<tmzt_g2root> still no panel
<tmzt_g2root> nevermind, it was just slow
<ogra_ac> NCommander, so building klibc brings intresting results in the buildlog
<tmzt_g2root> vte doesn't work, I have never seen that before
<ogra_ac> NCommander, it has -march=armv4 -mtune=strongarm hardcoded
<ogra_ac> (but given that has always been the casei wouldnt think that has any influence on our bug)
<NCommander> ogra_ac: yeah, was looking at that, but I think its irrevelent
<NCommander> klibc didn't help, nor did upstart
<ogra_ac> you rebuilt it ?
<NCommander> I tried downgrading the kernel to maverick release on a hunch
<NCommander> ogra_ac: yeah
<ogra_ac> what would upstart have to do with it ?
<ogra_ac> we are way before upstart
<ogra_ac> and as i said in the bug init=/bin/bash didnt work either
<NCommander> ogra_ac: sorry, meant to say that I don't htink upstart helps
<NCommander> ogra_ac: or part of it
<ogra_ac> no, upstart is out of scope here
<NCommander> right
<NCommander> Very very odd
<ogra_ac> i still think its the args that are messed up
<ogra_ac> try to add some schos to /init
<NCommander> ogra_ac: yeah, but what changed to kill the args
<ogra_ac> *echos
<ogra_ac> echo $@
<ogra_ac> echo ${rootmnt}
<ogra_ac> and
<ogra_ac> echo ${init}
<ogra_ac> see what that shows
<ogra_ac> also note that break= drops you into a subshell, so you cant run run-init manually
<NCommander> ogra_ac: how close are you to doing so? (I can rapidly respin the initrams ATM on my ac100, but if your already doing it ...)
<ogra_ac> i'm not even near my panda atm
<ogra_ac> just building klibc remotely with different options
<ogra_ac> so i would appreciate if you could test
<NCommander> ogra_ac: what script calls run-init? (or do I need to smack the code)
<ogra_ac>  /init
<ogra_ac> its a shell script
<ogra_ac> just add some echos
<ogra_ac> lives in /usr/share/initramfs-tools/init
<NCommander> ogra_ac: thanks. I thought you called run-init directly thoguh within a console with proper args and still got a crash
<ogra_ac> in the normal system
<ogra_ac> i tried that
<NCommander> ogra_ac: disclaimer: I don't get the run-init error, just the panic on the serial console
<ogra_ac> just to be told that wont work because i'm in a subshell
<ogra_ac> NCommander, you will get it on the monitor if you boot without splash
<ogra_ac> you will also get it if you boot with break=bottom and ctrl-d out of it to continue the boot
<ogra_ac> run-init will only work if called by pid 1
<ogra_ac> so you cant call it manually
<NCommander> ogra_ac: I don't have a monitor I can use in my "office"
<ogra_ac> then just break=bottom
<NCommander> ogra_ac: will do
 * NCommander kicks his ac100
<ogra_ac> and hit ctrl-d
<ogra_ac> did you finally manage to wear out your emmc ?
<ogra_ac> :)
<NCommander> ogra_ac: no, the USB controller is having mini-seizures
<ogra_ac> ah
<NCommander> and every once in awhile, it and my USB HDD decide to cause a process to become a zombie
<NCommander> very annoying when thats dpkg
<ogra_ac> just fix the kernel ;)
<NCommander> ogra_ac: not paid to do that ATM :-/
 * ogra_ac will spend a good part of his holiday improving the ac100
<tmzt_g2root> ogra_ac: tegra?
<ogra_ac> tmzt_g2root, yep
<NCommander> ogra_ac: \o/
<ogra_ac> NCommander, dont party to early, i will concentrate on moving PM and buttom management into the .29 kernel only
<NCommander> ugh
<NCommander>  /o\
<ogra_ac> for never kernel talk to marvin24
<ogra_ac> ;)
<ogra_ac> he has something based on .36, just misses a regulator specialist
<tmzt_g2root> regulator?
<ogra_ac> to power on the LCD i think
<ogra_ac> it boots to a serial USB console
<tmzt_g2root> clean up the nvidia oem stuff so it stops asking a binary layer to describe the hardware?
<ogra_ac> but has no device drivers yet
<ogra_ac> no, i will just revert the hacks tochiba put in
<tmzt_g2root> then get nouveu?? ported
<ogra_ac> and see that i get some sane defaults into the kernel
<ogra_ac> nah
<ogra_ac> i dont care about 3D drivers
<ogra_ac> i just need power management
<tmzt_g2root> the 2d is crtc only
<tmzt_g2root> lcdc
<ogra_ac> i need backlight on/off on lid close and want to have ondemand scaling working
<ogra_ac> extra points for dimming support
<ogra_ac> and a proper ubuntu initrd
<ogra_ac> thats my current focus for the vacation
<tmzt_g2root> you don't have an android phones do you?
<ogra_ac> nope, i have a sane phone
<tmzt_g2root> smart mount -t devpts devpts $MOUNTPT/dev
<ogra_ac> NCommander, want to have my klibc built for armv7 ?
<ogra_ac> or do you have one already ?
<NCommander> ogra_ac: haven't needed it yet
<ogra_ac> k
<NCommander> ogra_ac: got debugging data
<NCommander> ogra_ac: rootmnt is "/root"
<NCommander> init is "/sbin/init"
<NCommander> arguments: "fixrtc"
<NCommander> That was amazingly unuseful
<ogra_ac> yeah
 * NCommander throws it into the bug for completeness sake
<ogra_ac> i wonder if the bindmounted /dev is ok
<ogra_ac> i.e. if we get the right console
<NCommander> ogra_ac: easy way to test that
<NCommander> but run-init has a sanity check for that it should fail with "unable to open consoel" or something like that
<NCommander> and its the right major/minor for dev console
<ogra_ac> in /dev
<ogra_ac> i'm talking about $rootmount/dev
<ogra_ac> udev should move mount /dev to /root/dev, but i wonder what happens if that doesnt work/happen
<NCommander> ogra_ac: system would fallover
<ogra_ac> yeah, likely even before run-init
<NCommander> ogra_ac: I think you might be onto something
<NCommander> /root/dev is populated
<NCommander> we have a newer upstream udev
<NCommander> and udev sometimes breaks backwards compatilbility with older kernels
<ogra_ac> see /usr/share/initramfs-tools/scripts/init-bottom/udev
<NCommander> and mainline kernel is on 37
<NCommander> hrm
<ogra_ac> probably add some ls in there
<NCommander> give me a sec, I want to check something else first
<ogra_ac> before the move ls /dev
<ogra_ac> after the move ls /root/dev
<ogra_ac> and compare
<NCommander> ogra_ac: I'm trying to downgrade udev
<NCommander> to maverick
<NCommander> just rule it out completely
<ogra_ac> k
<ogra_ac> maverick has 162
<ogra_ac> natty 164
 * ogra_ac checks changelogs
<ogra_ac> looks okayish
<NCommander> ogra_ac: no love there, udev downgrade and still a hang
<NCommander> I'm runng out of things to downgrade
<ogra_ac> so want my klibc package ?
<NCommander> ogra_ac: sure althoguh at this point I don't think it will help
<ogra_ac> i dont think it either
<NCommander> ogra_ac: doing the ls devs doesn't reveal anytthing interesting
<NCommander> I'm running out of ideas
<ogra_ac> http://people.canonical.com/~ogra/libklibc_1.5.20-1_armel.deb and http://people.canonical.com/~ogra/klibc-utils_1.5.20-1_armel.deb
<mellis> her where would i go to report / check a bug in the omap kernel
<NCommander> mellis: downgrading the kenrel didn't fix it
<NCommander> Don't think this is a kernel problem, probably something with userland
<mellis> i upgraded my kernal and it fixed my sound problem but my s-video went dead
<NCommander> ogra_ac: I'm wonder ...
 * NCommander is starting to think run-init == redherring
<ogra_ac> yes
<ogra_ac> thats why i looked at the args
<ogra_ac> what do you suspect ?
<sveinse> Anyone there knows the correct gcc options for TI OMAP3?  -march=armv7-a -mtune=cortex-a8
<NCommander> ogra_ac: well, ... I'm not so sure now. I just tried replacing /sbin/init on my panda with /bin/bash, and letting it boot and it just fell over regardless
<ogra_ac> ??
<ogra_ac> you mean in the rootfs ?
<NCommander> yeah
<ogra_ac> well, we dont get to the rootfs
<NCommander> We're getting as far as the execve() call
<ogra_ac> no matter what you use
<NCommander> ?
<NCommander> oh
<NCommander> yes
<ogra_ac> i tired init=/bin/bash already
<GrueMaster> on a different note, I did some preliminary testing of the linaro kernel on my BeagleXM, and it seems ok.  Rythmnbox has issues, but I am able to get test sounds to play (R & L are reversed).
<NCommander> what the hell could cause an exec() call to crap itself?
<ogra_ac> GrueMaster, awesome, can you let apw know ?
<ogra_ac> then we have fulfilled our workitems
<ogra_ac> for the kernel team
<NCommander> ogra_ac: execve is a straight systemcall, but we're not getting an OOPS
<NCommander> something bloody odd is going on
<ogra_ac> why would you get an OOPS ?
<NCommander> ogra_ac: er, right, a bad syscall won't cause that
<NCommander> ugh
<NCommander> */brain fart*
 * NCommander rebuilds klibc with debugging info
<GrueMaster> yea, I can smell it in here.  :P
<ogra_ac> the OOPS you see has not much to do with run-init failing
<NCommander> ogra_ac: yeah, I got that
<ogra_ac> the OOPS you see is simply the kernel not finiding init
<NCommander> right
<NCommander> hrm
<ogra_ac> which you also get on older releases if init isnt executable or available
<ogra_ac> ignore the kernel in this context its all run-init
<GrueMaster> ogra_ac: I updated the kernel whiteboard for that task.
<NCommander> ogra_ac: right, so I'm rebuilding it now with -O2 -g, and will see if I can attach a debugger to it
<ogra_ac> GrueMaster, merci
<NCommander> (knowing our luck, that will mysteriously fix it)
<ogra_ac> NCommander, did you test with my v7 build from above ?
<ogra_ac> http://people.canonical.com/~ogra/libklibc_1.5.20-1_armel.deb and http://people.canonical.com/~ogra/klibc-utils_1.5.20-1_armel.deb
<ogra_ac> NCommander, ^^^
<jcrigby> what if you can't run any executable on rootfs because of some weird ld.so.blah mismatch
<ogra_ac> hmm
<tmzt_g2root> with klibc?
<ogra_ac> yeah, someone should try booting with a maverick initrd
<ogra_ac> tmzt_g2root, klibc is only used in initrd
<tmzt_g2root> not paying close enough attention
<tmzt_g2root> I've got crazy stuff like this but not to the point of err values getting overwritten
<tmzt_g2root> but, you could try init=/lib/ld-linux.so.3
<tmzt_g2root> and see if it prints anything
<tmzt_g2root> dcordes: you had efl and panel at the same time? I can't get that to work
<mellis> why wont the omap kernels work with s-video
<GrueMaster> It isn't an easy interface to test.
<tmzt_g2root> mellis: missing i2c controller driver?
<GrueMaster> Not sure if it is just a config flag or it requires more kernel work.
<mellis> no idea
<tmzt_g2root> sorry encoder
<mellis> i have one kernel that works
<GrueMaster> The only thing I have available for testing that output is my 42" LCD in the livingroom, but it is very difficult to get setup for svideo.
<mellis> yeah i only have a s-video tv so ima bit stuck
<sveinse> hrw|gone: Here is bug #683832 as instructed.
<ubot2> Launchpad bug 683832 in gcc-4.4-armel-cross (Ubuntu) "gcc fails to cross compile Qt (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/683832
<sveinse> I reported the bug in gcc-4.4-armel-cross, but it also applies to gcc-4.5-armel-cross. Do I need to add a new bug, or can I link them for both packages?
<NCommander> ah haw
<NCommander> might figured out what broke
<ogra_ac> tell me
<jcrigby> the suspense is killing us
<NCommander> ogra_ac: or not
<NCommander> but if I set init to /bin/dash
<NCommander> it works
<NCommander> the plot thickens
<NCommander> er
<NCommander> maybe not
<NCommander> strange
<NCommander> as soon as run-init runs, it breaks the enviornment
<ogra_ac> no, /init unsets most of it
<NCommander> ogra_ac: I'm referring to running run-init directly
<ogra_ac> before it runs run-init
<NCommander> if I runit through strace, it makes some very pretty output and works
<NCommander> (sorta)
<ogra_ac> you cant run it from a pid other than 1
<NCommander> I get the same sorta errors though
<ogra_ac> (you cant run it from the initramfs shell)
<ogra_ac> if you want to strace or gdb it you have to do that inside /init
<ogra_ac> you can never do it manually
<NCommander> strace isn't very useful
<NCommander> kernel panics before it finishs printing debug info
<ogra_ac> and gdb will be painful to get commands in
<NCommander> ogra_ac: indeed
<NCommander> I'm nearly out of ideas here on how to debug
<jcrigby> I just did a diff on a good initrd vs a bad one and other than binaries the only diff is this:
<jcrigby> diff -ru goodtree/init badtree/init
<jcrigby> --- goodtree/init       2010-12-01 13:41:26.376116002 -0700
<jcrigby> +++ badtree/init        2010-12-01 13:41:26.796116002 -0700
<jcrigby> @@ -53,6 +53,11 @@
<jcrigby>  export resume=
<jcrigby>  export resume_offset=
<jcrigby>  
<jcrigby> +# mdadm needs hostname to be set. This has to be done before the udev rules are called!
<jcrigby> +if [ -f "/etc/hostname" ]; then
<jcrigby> +        /bin/hostname -b -F /etc/hostname 2>&1 1>/dev/null
<jcrigby> +fi
<jcrigby> +
<ogra_ac> yeah, i checked that already
<jcrigby>  # Bring in the main config
<NCommander> jcrigby: PASTEBIN PLEASE
<jcrigby>  . /conf/initramfs.conf
<jcrigby>  for conf in conf/conf.d/*; do
<jcrigby> NCommander, I figured it was short enough
<jcrigby> sorry
<ogra_ac> and we dont have /etc/hostname inside initrd
<ogra_ac> so thats a noop
<NCommander> jcrigby: can you do a diff to tell us what binaries changed between last known good and current?
<ogra_ac> but we also have a new udev and i see some systemd code in it, but then why wouldnt that also fail on other ubuntu images
<NCommander> ogra_ac: downgrading udev didn't help
<NCommander> frustatingly enough
<ogra_ac> how did you downgrade udev ?
<NCommander> ogra_ac: apt-get install udev=162-2 && update-initramfs -u
<ogra_ac> that wont clean up anything
<ogra_ac> just overwrite
<NCommander> ?
<ogra_ac> you could as well do dpkg -x udev*.deb /
<ogra_ac> if there are new binaries in the newer udev they will still persist
<NCommander> ogra_ac: well, do you have any better ideas?
<ogra_ac> no
<NCommander> ogra: why would the new binaries persist?
<ogra_ac> because there is nothing removing them
<ogra_ac> the only sane way to test that would be to take maverick and step by step upgrade
<NCommander> ogra_ac: dpkg will remove files that only exist in the old package as part of a downgrade
<ogra_ac> but thats painful and will take lots of time
<NCommander> ogra_ac: I'm out of ideas TBH
<NCommander> and I don't know a good way to debug run-init
<ogra_ac> i dont think its run-init itself
<ogra_ac> a good test to see if its actually userspace would be to: boot maverick with init=/foo break=bottom ... then ctrl-d as you do it in natty and see if you get the same error
<ogra_ac> or make /sbin/init unexecutable or some such instead of init=/foo
<jcrigby> ok full diff here http://pastebin.ubuntu.com/538798/
<NCommander> ogra_ac: exec() is failingin run-init
<ogra_ac> exec of the subprocess for /sbin/init, no ?
<NCommander> so the differences are udev, the kernel, busybox, console-setup, and initramfs-tools
<NCommander> and some support libs
<ogra_ac> busybox ... hmm
<ogra_ac> ignore initramfs-tools
<ogra_ac> thats only the hostname stuff
<ogra_ac> wait-for-root can be ignored, we have it mounted properl at that point
<NCommander> don't think its libuuid
<NCommander> libc had an upgrade though
<ogra_ac> i think all of the stuff at the bottom thats in sbin can be ignored actually
<ogra_ac> libuuid is fine
<NCommander> I'm pretty sure its not udev
<ogra_ac> else you wouldnt have /root mounted
<NCommander> cause we would have seen breakage during mounting
<ogra_ac> libc didnt change between maverick and natty
<ogra_ac> i guess libgcc did
<ogra_ac> but i wouldnt know what effec that should have
<ogra_ac> the best candidate is busybox
<ogra_ac> the only big difference we have is the kernel vs x86
<NCommander> ogra_ac: glibc had an upgrade
<ogra_ac> and linaro as well is on .35 ( jcrigby might correct me)
<ogra_ac> NCommander, not in natty
<NCommander> ogra_ac: have we had any working natty images?
<GrueMaster> not that I know of.
<ogra_ac> nope
 * ogra_ac doesnt see any eglibc uploads 
<ogra_ac> nor any syncs that wuld have been processed
<ogra_ac> NCommander, the only image that was tested before yesterdays and todays was the one from the 19th and GrueMaster reported the same issue with that one
<GrueMaster> Sorry I couldn't debug it further.  I found it late that Friday and spend the working part of the following week testing maverick-proposed and doing bug triage.
<ogra_ac> dont worry
<ogra_ac> NCommander, https://launchpad.net/ubuntu/+source/eglibc 2.12.1-0ubuntu9  in maverick and natty
<dcordes> tmzt_g2root: yes. that works for me in the ootb une-efl session as well as in the hacked gnome efl session
<dcordes> tmzt_g2root: (panel and efl)
<dcordes> tmzt_g2root: did you post to the X ml yet ?
<NCommander> ogra_ac: I have no idea ATM, it possibly could be udev but that seems unliekly
<NCommander> GrueMaster: do we know if maverick->natty upgrades work on armel?
<ogra_ac> why shouldnt they ?
<ogra_ac> at this state of the relase they are manual work anyway
<GrueMaster> hasn't been tested yet.
<NCommander> ogra_ac: because someone wanted to try it, or do dev work?
<ogra_ac> well, as i said, it will be a lot of manual work anyway atm
<GrueMaster> dmesg
<GrueMaster> wrong window (again)
<ogra_ac> NCommander, so what we could try is to do piecemeal updates of the bits that end up in intramfs
<ogra_ac> and rebuild the initrd after each updated package
<ogra_ac> then we should see where it breaks
<NCommander> ogra_ac: thinking about it right now. I think we're going to miss A1 though
<ogra_ac> NCommander, if you dont feel like doing that i will do it tomorrow, its past 10pm here and i dont count on us making A1 anymore so i will soon stop working
<NCommander> I'm just mentally thinking
<ogra_ac> but i think piecemeal upgrade step by step is the best way to find the bad guy
<ogra_ac> GrueMaster, btw, are you sure your monitor issue isnt something similar ? i.e. is the board still alive even without screen ?
 * ogra_ac just sees that eglibc in maverick release isnt actually the one in natty 
<ogra_ac> the one in natty is the same as in -updates and one up from -security
<GrueMaster> I reimaged on a faster SD card and haven't been able to reproduce that issue.
<GrueMaster> The Sd card I had initial issues with was a class 2 4G (all I had available at the time).
<GrueMaster> I'm currently running maverick with the latest proposed updates and other than getting lost during screensaver, it is working fine now.
<GrueMaster> Unfortunately, my es2.1 is currently tied up with lmbench testing and NCommander has the other panda.
<GrueMaster> I can try updating my XM image to see if I can get it to break.
<ogra_ac> that would help too, given that linaro sees the issue with beagles
<ogra_ac> if you find anything, dump it on the bug
#ubuntu-arm 2010-12-02
<Sp0tter> does ubuntu run on the Kindel 3?
<DanaG> hmm, what's a good ubuntu-supporting ARM thingy with gigabit ethernet AND sata?
<DanaG> Marvell's old Kirkwood doesn't do armv7l.
<hrw> morning
<hrw> did someone here noticed problems with latest natty amd64 kernel and ftdi_sio usb-serial dongles?
<ogra_ac_> JamieBennett, so there is a ton of changes between maverick and natty in busybox, will take a while to identify the one at fault
<JamieBennett> ogra_ac: indeed, I took a look earlier and came to the same conclusion
<ogra_ac> the prob is that we only have very few merges between the changes
<ogra_ac> i still dont get why tgall_foo has it working on one board
<JamieBennett> me neither
<ndec> rsalveti: ogra_ac: hi. i just entered #684165, in case it rings a bell to you...
<rsalveti> bug 684165
<ubot2> Launchpad bug 684165 in pulseaudio (Ubuntu) "Pulseaudio FTBS on PandaBoard with -j2 (affects: 1) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/684165
<tmzt_g2root> ogra_ac: what shell is used in initrd?
<ogra_ac> tmzt_g2root, busybox
<tmzt_g2root> statically linked or against klibc?
<ogra_ac> nothing but run-init links against klibc
<ogra_ac> liked against glibc
<avinashhm> hi, is any one familiar with lockdep asserting bugs .. I am stuck with a deadlock bug ..i wanted to know if a single task can hold multiple mutexes ???.. error @  @ http://paste.ubuntu.com/539017/ ... any help ???
<GrueMaster> ogra_ac: Can the failing busybox be tested w/o having to run in initrd?  I.e. can it be launched in a chroot?
<ogra_ac> no
<ogra_ac> well
<ogra_ac> its exec that fails somehow
<ogra_ac> you could try to use exec from it
<ogra_ac> but the busybox-initramfs binary is built with different options than the normal busybox binary 8teh package does three build passes)
<GrueMaster> I understand.  But that shouldn't mean that it can't be executed in a chroot environment after being built.
<GrueMaster> And I would think you would have better control over it in that environment (i.e. not killing the system).
<ogra_ac> sure, well, its fixed now
<ogra_ac> more important is that we test the new images
<GrueMaster> I thought you were still going to look for the offending patch or something.
<ogra_ac> nah
<GrueMaster> btw:  just got a blank email that the image failed to build.
<ogra_ac> upload happened hours agi, bug is closed
<ogra_ac> colin might have canceled it
<ogra_ac> since he just gave me a ubiquity fix to test
 * ogra_ac needs to relocate and test that now
<ogra> phew, damned stairs
<ogra> one day i'll put an elevator in this house
<rsalveti> ogra: it'll probably help if you stop smoking :-)
<GrueMaster> I keep saying the same thing, but since NCommander is upstairs, the desire for me to use it diminishes greatly.
<ogra> well, i could put an ashtray in the elevator
<GrueMaster> heh
<GrueMaster> Just open a window and sit on the ledge.
<ogra> we have -10Â°C here
<rsalveti> hehe
<hrw> about say here
<ogra> only ? i thought poland was colder
<GrueMaster> And this bothers me...how?
<hrw> ogra: depends on part
<ogra> ah
<GrueMaster> You could turn a spare room into a smoking room.  The ones I have seen at the Atlanta, Georgia airport look like you are looking into a fog bank.
<ogra> why the heck would i do that ?
<GrueMaster> because it is -10c outside?
<ogra> so you think i would sit in a single room while my GF walks smoking through the house ?
<GrueMaster> Then why put an ashtray in the elevator?
<ogra> because i could smoke while going up and down ?
 * ogra guesses GrueMaster just didnt get the joke above
<ogra> go and take a coffee bath ;)
<ogra> geeez, natty looks ....
<ogra> ... well like maverick
<ogra> GrueMaster, the image failed to build because of ubiquity being out of sync (FYI)
<rsalveti> haha, at least for us it should look quite the same
<ogra> yeah
<ogra> the firefox icon has new text
<ogra> thats the most noticeable difference
<ogra> GrueMaster, also, if you want to test the new image, you will need this fix http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/4446
<ogra> (just gets uploaded now)
<GrueMaster> What new image?  I thought it was canceled or failed to build.
<ogra> right, colin just restarted the build
<GrueMaster> But it will still need this fix?
<ogra> he missed the publisher on arm
<ogra> yes
<ogra> that one only just gets uploaded now
<ogra> our image should be done by about the same time the fix hits the archive
<ogra> no way to get that into the image now
<ogra> its two lines in a python file, easy to quickly hack into the SD card
<GrueMaster> ok
<ogra> with it and the fixed busybox everything looks really good over here
<ogra> working sound OOTB \o/
<janimo> NCommander: I did a mono build on kakadu. The make check pass fails though, it does not get to the summary of the test run. Many errors (SIGSEGV)
<janimo> will try on beagle when I get it
<janimo> although the bugs are probably the same as the ARM core is similar from what I see
<rsalveti> GrueMaster: ogra: just finishing the installer with the busybox and uniquity fix, seems to be working well
<rsalveti> good to test the linaro's kernel for omap 3 later
<janimo> rsalveti: uniquity, hmm. Are two projects merging? ;)
<rsalveti> haha, *ubiquity
<dmart> pm215, markos_: here's what the first snippet should maybe look like: http://pastebin.ubuntu.com/539061/
<GrueMaster> rsalveti: I have already been doing some testing of the linaro kernel on XM.  Is there anything specific I should test?
<rsalveti> GrueMaster: nops, would just be good to test the 37 with natty, and see how it goes
<rsalveti> because this is our target to use the linaro's kernel
<GrueMaster> ok, I'll start my image updating to natty.  Currently running maverick-proposed.
<ogra_ac> look, more arm netbooks !
<ogra_ac> http://www.visual-land.com/vl760_black.html
<ogra_ac> *g*
<rsalveti> ARM 248MHz 32 Bit-CPU
<rsalveti> Embedded Windows CE 5.0 Operating System
<rsalveti> hehe
<rsalveti> ram 64MB
<ogra_ac> well, available in black *and* white
<rsalveti> hahah
<GrueMaster> amazon.com has a lot of new arm based systems, but the vast majority are arm9 or arm11.
<ogra_ac> i guess that onesis also arm9
<ogra_ac> *one is
<GrueMaster> Windows CE 5.0?  Ancient.  (equivalent to Windows 2000).
<ogra_ac> yep
<GrueMaster> I wonder if the new color Nook uses the more recent (i.e. fixed) imx51 chip, or if it is hobbled like the netwalker version.
<GrueMaster> Oh, nevermind.  It is an omap 3621.
<GrueMaster> I.e. BeagleXM.
<ogra_ac> doesnt that have backlight and wifi etc ?
<ogra_ac> i.e. everything i dont want on a reader :)
<tmzt> GrueMaster: omap, yeah
#ubuntu-arm 2010-12-03
<surferdude> Hi all, I just tried to build Ubuntu 10.10 for my BeagleBoard xM. On the serial console I get a login prompt but I don't know what to type in. Does anyone know what the default is?
<surferdude> I'm not even getting any video output on the hdmi port
<GrueMaster> It depends on what image you used and what rev board you have.
<GrueMaster> surferdude: ^^^
<Sp0tter> are there any ebook readers taht run ubuntu?
<Sp0tter> (v-ink displays, not tft)
<hrw> morning
<dex`> g.m.
<ranjith> hi all
<ranjith> is there only ubuntu netbook for omap4 blaze ..?
<ranjith> or is there any noraml ubuntu image avalable for omap4 blaze .?
<rsalveti> ranjith: you mean the default ui?
<ranjith> yes
<rsalveti> you can install whatever ui you want later on
<rsalveti> the netbook efl is just the default
<ranjith> ok. so that means only the netbook binaries are available for omap4 blaze..
<rsalveti> yes
<ranjith> but this is not that much different form default one..
<rsalveti> it's the only image we're producing for arm
<ranjith> so first i have to get the netbook prebuilt image running and then unstall the default ui if required..
<rsalveti> yes
<ranjith> one more doubt.. is there any reason that there is not arm ubuntu with the default ui ..?
<ranjith> because I want to develope some applications that is intended to run in ubuntu running in omap4 blaze ..
<ndec> ogra: rsalveti: hi! have you tried already a USB headset on panda?
<rsalveti> hm, not yet, but can easily try
<rsalveti> let's see
<ogra_ac> nope, but it should just work
<ndec> ogra: rsalveti: it does not work for me. I can see the the USB driver detects the USB peripheral, and the model (logitech), but PA does not see it.
<ogra_ac> weird
<ndec> if i compare when I plug the same headset in my laptop I have one extra debug mess in dmesg: usbcore: registered new interface driver snd-usb-audio
<ndec> perhaps something broken in the kernel config
<ogra_ac> hmm
 * ogra_ac checks
<ndec> bug USB_AUDIO and SND_USB_AUDIO are set
<ogra_ac> ah, crap, my panda isnt booted
<ndec> ogra: that can be fixed easily ;-)
<ogra_ac> no, i have to go to my office for that ;)
<ndec> damn it!
<rsalveti> currently I'm on natty, and my logitech usb headset worked fine
<rsalveti> let my try on maverick
<ogra_ac> hatty hs definitely all the fixes, probably ndec misses one on maverick
<rsalveti> just booting maverick
<ndec> rsalveti: ogra: well it looks like my panda does not my usb webcam too... crashed the board
<ogra_ac> ouch
<ogra_ac> that sounds like some more low level problem
<rsalveti> ndec: also worked fine
<rsalveti> same way as natty
<ndec> rsalveti: for sound or cam?
 * rsalveti currently listening absolute classic rock radio on rhythmbox
<ndec> over wlan?
<rsalveti> ndec: sorry, sound
<rsalveti> nops, ethernet, but should be fine over wlan
<rsalveti> ndec: are you using the default ubuntu kernel for panda?
<ndec> rsalveti: ogra: ok. so ASOC detects it. i can see the headset in /proc/asound. so it's something with PA config ;-) since I am using a custom config, that might be the problem...
<rsalveti> probably
<ndec> rsalveti: no, i am using a more recent kernel with power management ;-)
<ogra_ac> aha
<ogra_ac> you didnt say that ;)
<rsalveti> ndec: cool, is it working fine already?
<ogra_ac> changed pulse config will very likely break it
<ndec> not too bad.
<ndec> you should be able to build from sebjan tree, btw.
<ndec> or better, we should push a package in the PPA
<rsalveti> true, just need to fine time to do some testing
<rsalveti> *find
<rsalveti> we should also ask cooloney to help testing this tree
<ogra_ac> ndec, cooloney should just shove it into natty
<ogra_ac> so we get wider user testing
<rsalveti> at least for now it should be fine if we get into natty
<ndec> sebjan: ^^^ any thoughts?
<rsalveti> later on when we fully tested it we can port it to maverick
<ndec> it's .35 based, still.
<ndec> but you might be right... let's discuss in the call !
<ndec> it will break the ducati stuff.
<ogra_ac> oh, that will make robclark cry
 * rsalveti runs to get some food before the call
<ogra_ac> oh, good idea
<ndec> ogra_ac: this is a 4PM call for you ;-) no need for food...
<ogra_ac> ndec, i have a 2h release meeting right after it
<ndec> ogra: ;-)
<ogra_ac> (and then vacation til end of the year) ;)
<janimo> ogra, rsalveti is there another call shortly?
<Sp0tter> are there any ereaders with the e-ink displays taht work with ubuntu
<armin76> Sp0tter: doubt there any armv7 ebooks
<Sp0tter> drats
<Sp0tter> i just bought a kindle3
<Sp0tter> was hoping to do more with it than just read books :(
<ogra_ac> armin76, there are
<Sp0tter> really just wanted an ssh client
<armin76> ogra_ac: examples?
<ogra_ac> the nook is v7 based afaik
<armin76> Sp0tter: you don't need ubuntu to have an ssh client...debian could do, for example
<Sp0tter> yea taht would work fine too
<Sp0tter> i don thave an ubuntu preference over debian
<Sp0tter> i just figured thisis a good place to ask about linux on devices
<armin76> ogra_ac: nookdevs.com/teardown says armv6
<ogra_ac> the new one with the color display is supposed to be omap based
<Sp0tter> seems to be more interest in the nook than kindle
<Sp0tter> for third party devs
<Sp0tter> why is that
 * ogra_ac wonders why anyone would do anything beyond reading with an ebook reader
<Sp0tter> why not?
<ogra_ac> for arm development there are cheaper or more powerful systems
<Sp0tter> people also hack ebooks to add more fonts and languages
<Sp0tter> but if you are going to take your book somewhere, why not take IRC also
<ogra_ac> because i usually have my ac100 in my bag anyway ;)
<Sp0tter> you said people
<Sp0tter> not you
<Sp0tter> heh
<robclark> ndec / ogra_ac: libdce (and therefore gst-ducati) already works with L24.11 kernel...  if the issue you were worried about breaking ducati was related to kernel migration..
<ogra_ac> you said you above ;)
<armin76> ogra_ac: right, the nook color is omap3621
<ndec> robclark: if you are authorized to release ducati firmware for L24.11 then I should be too ;-)
<Sp0tter> ogra_ac: what do you liek about th eAC100 over  a regualr asus EEE netbook
<robclark> ndec: you don't need to change the codecs.. the only parts I had to update for L24.9->L24.11 was libdce which is already opensrc ;-)
<ogra_ac> Sp0tter, its arm and i can do my development work on it
<hrw> Sp0tter: size?
<ogra_ac> Sp0tter, beyond that you need to physically compare them
<robclark> ndec: and btw, it already has some error recovery/cleanup that the official fw doesn't have ;-)
<ogra_ac> ac100 is a quater of the weight and has no moving parts inside
<Sp0tter> hrw: are you asking me?
<hrw> Sp0tter: ac100 (or efikasb) are ~half of atom netbooks
<ogra_ac> its as thin as a folder
<ndec> robclark: well, that's because you don't use OMX!
<robclark> it does simplify some things, doesn't it ;-)
<ndec> robclark: definitely.
<Sp0tter> i wodner if its really worth it to get a closed-device like a Kindle to have the e-ink over a regualr screen
<Sp0tter> was only $140
<hrw> you can always sell it or give as a gift to someone
<Sp0tter> thats true
<Sp0tter> i think i can return it to amazon in 30 days with no restocking fee also
<Sp0tter> supposed to get here on monday
<Sp0tter> but i've been getting more skeptical since i ordered it heh
<hrw> or you will start to use it
<Sp0tter> yea i may love it, i just hate to know it could also use irc
<Sp0tter> but it can
<Sp0tter> cant
<hrw> Sp0tter: eink has slow refresh
<hrw> Sp0tter: it you want something for irc and such size then nook color (or other android tablet) would be better
<Sp0tter> i want ebook reader first
<Sp0tter> then other features second
<Sp0tter> i have a good netbook arleady
<hrw> netbooks... I have efikasb here and it is good only for light use. even with 2GHz dualcore x86-64 I would prefer to not use this size of device as main one
<Sp0tter> my main computer is a 4gh 6 core athlon
<Sp0tter> :)
<hrw> I am waiting for buldozer cpus
<Sp0tter> what's the best android tablet out?
<hrw> no idea
<ogra_ac> ndec, bug 664431
<Sp0tter> why is that AC100 so expensive?
<ubot2> Launchpad bug 664431 in qt4-x11 (Ubuntu Natty) (and 3 other projects) "QT on armel is built with NEON by default (affects: 4) (dups: 1) (heat: 44)" [High,Triaged] https://launchpad.net/bugs/664431
<Sp0tter> it hoguht the arm based laptops were looking to be cheap
<Sp0tter> the kindle3 is $140 + free shipping on aazon, and its going on ebay for $180 shipped
<Sp0tter> ebay is retarded.
<ogra_ac> ndec, http://cdimage.ubuntu.com/ubuntu-netbook/releases/natty/alpha-1/
<rsalveti> cool, can see the link already :-)
<rsalveti> there we go, alpha-1 image for panda
<rsalveti> ogra_ac: change the topic :-)
<ogra_ac> yeah
* ogra_ac changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch |  wanna cross build ? http://42.pl/u/2u8U | Natty aplha 1 at http://cdimage.ubuntu.com/ubuntu-netbook/releases/natty/alpha-1/
<ogra_ac> :)
<rsalveti> ogra_ac: typo: aplha/alpha
<ogra_ac> oops
* ogra_ac changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch |  wanna cross build ? http://42.pl/u/2u8U | Natty alpha 1 at http://cdimage.ubuntu.com/ubuntu-netbook/releases/natty/alpha-1/
<ogra_ac> sorry for the noise
<rsalveti> now it's fine :-)
<ogra_ac> bug 663642
<ubot2> Launchpad bug 663642 in linux-linaro (Ubuntu Maverick) (and 3 other projects) "DVI doesn't work at BeagleBoard xM rev A3 (affects: 1) (heat: 97)" [Undecided,Fix released] https://launchpad.net/bugs/663642
<ogra_ac> bug 673509
<ubot2> Launchpad bug 673509 in linux (Ubuntu) "Beagleboard-xm chooses a new IP address on each boot (affects: 1) (heat: 176)" [Undecided,Confirmed] https://launchpad.net/bugs/673509
<ogra_ac> bug 673504
<ubot2> Launchpad bug 673504 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "Pandaboard chooses a new IP address on each boot (affects: 2) (heat: 192)" [High,Fix committed] https://launchpad.net/bugs/673504
<ogra_ac> rsalveti, GrueMaster, arent the latter two "fix released" ?
<rsalveti> probably, let me check
<GrueMaster> I think they were in the .19 release kernel which is still in proposed.
<ogra_ac> ok
<rsalveti> ogra: the first one, for beagle is not yet released
<ogra_ac> yeah, fine then
<rsalveti> ogra: for panda is already on proposed, but not at updates yet
<ogra_ac> ok
<rsalveti> ogra_ac: just to know, were you able to do some work on the alsa-utils update bug?
<rsalveti> that got into main accidentally
<ogra_ac> rsalveti, nope, not yet
<rsalveti> ok, np, just to know
<ogra_ac> thats why its still on the release report
<ogra_ac> (else i would have moved it from SRU to released)
<rsalveti> yeah, that's why I wanted to check with you
<rsalveti> ok
<LetoThe2nd> xdeb as mentioned in the topic breaks in the command "xdeb -aarmel --only-explicit --apt-source linux-linaro
<ogra_ac> LetoThe2nd, -> hrw
<LetoThe2nd> hrw: log/messages: http://pastebin.com/Vr9iUt8x
<Neko> anyone know how when you get a disk check happening it updates plymouth with a multi-line, progress counter display rather than just the lame plymouth --message stuff I've been using?
<Neko> is there a script somewhere in udev or initramfs-tools or something that does this?
<hrw> LetoThe2nd: known, fixed in newer versions iirc
<hrw> versions of linux-linaro
<LetoThe2nd> hrw: ok.. but the same or at least similar errors also occur if i just want to build some relatively simple thing, like screen for example.
<LetoThe2nd> hrw: like here, when trying bash.
<Neko> asking again anyone know how plymouth is sent the messages from disk checks and so on, with updating percentage and multiple lines of text?
<Neko> ohhhh I found it.. it's mountall
<GrueMaster> rsalveti: There?
<GrueMaster> It would appear that today's image does not have full networking capability.  Unfortunately, I am working with limited testing capabilities while in downtown Portland with the PDX team.
<GrueMaster> Had originally planned to work on my blueprint today.  Sigh.
<tmzt> got my chroot init program mostly working
<tmzt> might be useful for testing with Xephyr I don't know quite yet
<tmzt> it doesn't ptrace so it should work with qemu-arm
<dcordes> tmzt: hi! sounds good
<dcordes> congrats
<tmzt> dcordes: oh, and I had to build a new image, did the same instructions and launcher and panel work together perfectly
<dcordes> :)
<tmzt> yeah, now if it would just launch from the android app like it's supposed to
<dcordes> any new hacks we should document in htc linux wiki or in smartphone lp project ?
<tmzt> no, didn't need any
<dcordes> oh somebody added instructions on how to use adb in ubuntu !
<tmzt> I have script that mostly converts an ubuntu-minimal though
<tmzt> nice
<tmzt> with usb_composite that should work well
<dcordes> http://htc-linux.org/wiki/index.php?title=Ubuntu/Leo#ADB
<tmzt> adb+ether been waiting since g1 for that
<dcordes> could you publish the script ?
<tmzt> soon
<dcordes> that will be nice
<tmzt> have to tweak it a little bit
<dcordes> I tried to rootstock ubuntu-desktop recently and failed
<dcordes> did you use rootstock for the ubuntu-minimal ?
<tmzt> yes
<tmzt> just something -s ubuntu-minimal
<tmzt> dcordes: I have a vps to put a rootstock builder on, somebody just wrote some download code for us for the downloader
#ubuntu-arm 2010-12-04
<dcordes> tmzt: could you try making an ubuntu-desktop image with that ?
<dcordes> I am not sure when was the last time I succeeded with that using rootstock - which is why I switched to using the omap4 preinstalled images.
<tmzt> might be a little big but it should work, did you get my pm?
<aksh1> hi does Seiko 70WVW1TZ3 supports in ubuntu 10
<aksh1> hi all, does Seiko 70WVW1TZ3 TFT Module touch scrren good enough to test utouch
<aksh1> hi all, does Seiko 70WVW1TZ3 TFT Module touch scrren good enough to test utouch
<aksh1> which multitouch hardware is available to test utouch on arm
<dcordes> aksh1: join #ubuntu-touch
<dcordes> I tried rootstock 0.1.99.4 script in karmic . it says there is no qemu installed although qemu package was installed
<aksh1> dcordes, try upgrading qemu else u can edit rootstock script
<dcordes> aksh1: I can't find how to edit rootstock. is there some version check I am not seeing ?
<aksh1> dcordes, install qemu-arm-static
<aksh1> qemu-kvm
<aksh1> and then chk rootstock
<dcordes> I had some repositories missing so qemu install was incomplete
<aksh1> ok
<m4D_> hello. i'am writing some app for armv5te. i'm stuck with it crashing on code: u8 header[40]; fread(...); u32 var = *(u32 *)(header + 10); any ideas? possible alignment error?
<tmzt> m4D_: just a guess, but I don't think 10 is divisible by 4
<m4D_> tmzt: header is byte ptr, so it's offseted by 10 and then there 4 bytes i need to get into var. replacing it with memcpy(&var, header + 10, 4) works ok. btw, compiling it with emvc4 works ok too. but gcc-compiled code fails (
<tmzt> right, if your point isn't aligned and you do a 32 bit read (u32 var =) on armv5 it's going to abrt
<tmzt> or bus, not sure which
<m4D_> so, are there any flags to gcc that somehow optimize such constructions? emvc4-code for wince works ok - how does he fixes it?
<hrw> maybe adds padding?
<tmzt> porting from ce/
<tmzt> m4D_: ask in #hpcdev if your curious
<m4D_> tmzt: ok, thanks
<tmzt> hrw: how would you suggest running an init-like process in a chroot? with so much being converted to upstart just launching rc scripts doesn't appear it would work, so I've been developing an init/xinit replacement for this purpose
<Crisco> does anyone here have a SheevaPlug?
<tmzt> I'm having a number of issues, including the age old problem of not being able to track forked processes
<hrw> tmzt: never did such
<hrw> Crisco: I do
<Crisco> hrw: how well does it work?
<Crisco> is it something you'd recommend?
<hrw> Crisco: with angstrom or debian it flies.
<Crisco> but the preinstalled Ubuntu distro doesn't do well?
<hrw> Crisco: 600-800Mbps over ethernet, 30MB/s on usb
<hrw> Crisco: jaunty is not supported
<hrw> Crisco: first thing to do with sheeva is installation of distro with support
<Crisco> really? where did you buy yours from?
<hrw> globalscale directly
<Crisco> ah
<Crisco> how long did it take to get yours?
<hrw> Crisco: but consider guruplug - sata port is useful
<Crisco> so with sata you'd be able to get a HD and connect it to the GuruPlug
<hrw> Crisco: at that time they had backorder so ~month. when they are on stock it is just fedex+2 days?
<hrw> Crisco: yep
<hrw> Crisco: I used 1.5TB in usb enclosure
<Crisco> I thought about the GuruPlug Display, but they don't have them yet...
<hrw> Crisco: first define what for you buy it
<Crisco> I wanted a computer that could be on 24/7 that would be able to store my files and maybe allow me to access them from school.
<Crisco> and when I saw the GuruPlug Display, I realized that it could be an awesome media pc
<Crisco> I was planning on having it stream music with MPD anyways
<Crisco> not sure if MPD would work though
<Crisco> I don't know much about different CPU architectures and what does and doesn't work
<hrw> ok
<tmzt> mpd is compiled from source
<hrw> guruplug will probably do not be able to decode highres videos
<Crisco> the highest res I have is 480p
<hrw> if you want NAS then guruplug+debian will fly for you
<hrw> for mediapc I would go for miniitx atom or atom+ion even to get HD decoding
<hrw> some will suggest pandaboard for mediapc
<Crisco> I don't need a media PC, the TV we are getting would allow for me to plug my laptop into the TV whenever I wanted to watch something on it, but I would like to stream audio
<tmzt> dcordes: did you get those images to build?
<tmzt> Crisco: you might be able to do DLNA streaming as well, just don't expect transcoding to work well on a limited device
<hrw> Crisco: sheeva cpus will decode any audio
<Crisco> yeah
<Crisco> excuse me, I'm not very knowy in the area of networking, what is DLNA?
<tmzt> digital lifestyle network alliance, because a way to stream audio and video over networks with UPnP resolving
<tmzt> most newer TVs have built in clients
<hrw> if they have ethernet or wifi
<hrw> btw - does someone know how to remap keyboard on text console and x11?
<tmzt> I've played with it
<hrw> tmzt: efikasb has sick input devices
<tmzt> ah
<hrw> tmzt: keyboard has volume/media/etc instead of F1-F12 keys
<hrw> F1-F12 keys are only with Fn key
<tmzt> well for X for that you can probably use xmodmap
<tmzt> I would map Fn to RIGHTALT and use it as AltGr
<hrw> but normal (volume/media/etc) ones are on one input and F1-F12 ones on other input device
<hrw> looks like Fn is not seen by kernel
<tmzt> that's a problem
<tmzt> not on any input devices?
<hrw> evtest does not see it
<tmzt> cat /dev/input/event* doens't either?
<hrw> neither
<hrw> handled by hw probably
<tmzt> I think I have an older version of rootstrap
<tmzt> yeah, but then why don't you get keys when you do fn+1 or whatever?
<tmzt> what os does this thing normally have?
<hrw> if I press Fn+1 (when there is no such combo) then I get 1
<hrw> linux
<hrw> tmzt: look at keyoard picture on my blog: http://marcin.juszkiewicz.com.pl/
<tmzt> what type of keyboard is it? matrix on the soc? sio (like ps2)?
<hrw> tmzt: keyboard is one usb device, touchpad is second usb
<tmzt> ah
<hrw> fun is that keys on F1-F11 are handled by touchpad input device not keyboard input device
<hrw> sick as hell
<tmzt> wow yeah
<tmzt> it's a composite device or two ids?
<hrw> two
<hrw> Ã¼berksick
<tmzt> pgup/pgdn don't work either?
<hrw> with fn they work
<tmzt> hmm, but you get no event for the fn key
<hrw> fun is all keys works (except brightes up/down ones)
<hrw> but get event for Fn+Up which is PgUp
<hrw> hardware level probably
<tmzt> same as most acpi
<tmzt> but that doesn't solve the problem, if you don't get any events for the multimedia keys with fn
<tmzt> do you get it without?
<hrw> I get
<hrw> showkey, evtest, xev reports them properly
<hrw> but I want to find a way to have XF86VolumeMute to generate F1 and viceversa on console and x11
<tmzt> right, but you need the modifier for that
<tmzt> I don't get what's going on, unless the firmware is bad
<hrw> I will discuss it with vendor developers
<tmzt> does it work on the normal system or is this just hardware you have to install stuff to
<tmzt> oh right
<hrw> I hope to get info what guys which invented this smoke/took
<tmzt> it's not a hub or anything like that is it?
<tmzt> those wifi/radio cards are they on their own usb ports?
<tmzt> is there an official way to enabled universe from the command line?
<hrw> imx51 hub -> hub -> input+input+wifi, imx51 hub->hub->bt+video
<hrw> tmzt: sed -e "s/$/ universe/g" -i /etc/apt/sources.list should work
<tmzt> thanks
<tmzt> wow I didn't know -i
<hrw> or better s/maverick main/maverick main universe/g
<tmzt> now I was pretty sure rootstrip printed it's options
<tmzt> rootstrap
<Crisco> hrw: you said you have a GuruPlug too?
<tmzt> oh
<tmzt> I want rootstock
<hrw> Crisco: no, I do not have
<Crisco> oh... well, there seems to be alot of complaints about heat
<hrw> Crisco: I do not use sheevaplug even now - it just stays under desk
#ubuntu-arm 2010-12-05
<ranjith> hi all .. I was trying to get ubuntu 10.10 netbook workign on  my omap4-blaze ..
<ranjith> I downloaded the image from http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/10.10/release/
<ranjith> and followed the instruction from https://wiki.ubuntu.com/ARM/OMAPMaverickInstall
<ranjith> but when i inserted the sd card to my omap4-blaze and powered it up.. nothing is happening..
<ranjith> it is just dead..
<ranjith> any one ahve any idea .?
<ranjith> hello anyone here ..?
<ranjith> hello
<ranjith> I am not able to boot the ubuntu-netbook pre-installed image on omap4-blaze .. any one have any idea about how to boot it..?
<jo-erlend> natty a1 is out. Is there any rebuilt images for arm as well?
<ogra_ac> jo-erlend, see /topic
<ogra_ac> only omap4 atm though
<jo-erlend> oh... Sorry :)
<jo-erlend> oh, ok. When will there be support for omap3?
<ogra_ac> as soon as we have sorted out the kernel situation
<ogra_ac> the plan is to switch to the linaro kernel for omap3
<ogra_ac> but that needs some commitment from security and kernel teams
<ogra_ac> since linaro doesnt provide any support after release for their kernel
<ogra_ac> (no committed support at least)
<jo-erlend> oh, ok. But it will happen?
<ogra_ac> lool, what were the symlink errors you saw with x-loader ? i remember that getting the patch for the u-boot headers to work was very very tricky
<ogra_ac> (all headers are linked to out of tree files that only exist in the u-boot tree)
<lool> ogra_ac: It is with the u-boot headers patch
<lool> ogra_ac: I basically dpkg-source -x + debuild, and that breaks
<ogra_ac> well if you changed the upstream source it might not properly replace symlinks with files, thats what i meant
<ogra_ac> but seems you didnt do that
<ogra_ac> that would be my only explanation
<ogra_ac> when i last built it (i'm always using dpkg-buildpackage -b though) it worked fine
<ogra_ac> (that was when you asked about signGP.c)
<lool> ogra_ac: I didn't change it
<lool> ogra_ac: Did you try it out?
<lool> ogra_ac: Grab x-loader-omap4 and try building it
<lool> I'm doing apt-get source and debuild -aarmel -us -uc -b on my desktop
<lool> dh_quilt_patch
<lool> Application de 01-add-missing-uboot-headers.patch
<lool> patching file include/asm/arch-arm1136/clocks.h
<lool> patch: **** Can't create file include/asm/arch-arm1136/clocks.h : No such file or directory
<lool> that's with L24.9git20100901-0ubuntu3, currently in the archive
<ogra_ac> builds flawless here
<ogra_ac> http://paste.ubuntu.com/539945/
<ogra_ac> patch applies fine
<ogra_ac>    dh_md5sums
<ogra_ac>    dh_builddeb
<ogra_ac> dpkg-deb: Baue Paket Â»x-loader-omap4Â« in Â»../x-loader-omap4_L24.9git20100901-0ubuntu3_armel.debÂ«.
<ogra_ac> and finishes fine
<ogra_ac> tar tzf ../x-loader-omap4_L24.9git20100901.orig.tar.gz |grep arch-arm1136
<ogra_ac> also returns proper dirs for me
<ogra_ac> s/dirs/files
<ranjith> I am not able to boot the ubuntu-netbook pre-installed image on omap4-blaze .. any one have any idea about how to boot it..?
<ogra_ac> ranjith, what silicon version is your blaze ?
<ogra_ac> note that ES1 isnt supported
<ranjith> ogra_ac: hi, how can i know the silicon version ..?
<ogra_ac> ranjith, good question, i dont know
<ranjith> also, while i pulled the card out and put in back in pc after lefting it on the device for some time, the card is formated again,.. ie it is note having hte partition as i had created..
<ranjith> sorry for that question, i am new to this board thats why i asked..
<ogra_ac> you created partitions ?
<ogra_ac> you shouldnt do that, the image needs to go to the device directly (mmcblk0)
<ogra_ac> it will repartition itself on first boot
<ranjith> so where should i put the MLO, ubooot and uImage ..?
<ogra_ac> in the first partition after you zcat'ed the image to the device
<ranjith> ok
<ogra_ac> you need to do the zcat, then remove and re-insert the card
<ranjith> so first i ahve to keep the card without any partition..
<ranjith> ok
<ogra_ac> after that you should be able to mount the first partition and replace the bootloader files
<ranjith> but i already did the gunzip.. and now the image is in .img format not .img.gz ..
<ogra_ac> the image is partitioned, so its essential that you write ti to the device, not to a partition
<ogra_ac> well, if you prefer the complex way, and gunzipped already, use dd instead of zcat
<ranjith> So let me try that. as i it is already gunziped i think there wont be any difference in doing dd other than zcat..
<ranjith> thanks for the help..
<ranjith> let me try this..
<ogra_ac> right, technically there shouldnt be a difference, it just eats your diskspace on the host
<ranjith> ok
<ranjith> ogra_ac: now i have flashed the image to the card .. should i copy the MLO, u-boot, uImage etc now.. or after the first boot only ..?
<ogra_ac> before
<ranjith> ok
<ogra_ac> re-plug the card
<ogra_ac> vfat should be mountable then
<ogra_ac> replace the files and boot the blaze
<ranjith> ok
<ranjith> both parttions are mounted..
<ranjith> and i ahve replaced the respective file sin the first partition..
<ogra_ac> k
<dcordes> tmzt: no space left
<dcordes> tmzt: but it seems I met all other requirements
<lool> ogra_ac: I found the issue with x-loader-omap4: it's ecryptfs
<lool> ogra_ac: it builds in my /tmp but not in my /home
<ranjith> ogra_ac: it is installed.. and working fine.. thanks for the help. good night..
<jo-erlend> how come rmadison doesn't show ARM?
<ogra_ac> lool, wow, thats bad
<tmzt> dcordes: desktop image? no space on the server or the image is too small?
<LetoThe2nd> when following https://wiki.ubuntu.com/ARM/RootfsFromScratch, it fails with qemu: fatal: VS[LR]I.64 not implemented
<LetoThe2nd> is this a known issue? qemu outdated?
<dcordes> tmzt: ah right. I didn't specify the image size... next try
<dcordes> LetoThe2nd: is that some conflict related to host platform ?
<dcordes> LetoThe2nd: x86 vs x86_64 ?
<LetoThe2nd> dcordes: don't know - i just tried on x64.
<dcordes> tmzt: looks good
<luis_> hello everybody, can I install ubuntu on a cheap sylvania  arm netbook
<tmzt> luis_: that requires a lot more information, but if it's the wmxxxx version then probably not, unless you install jaunty
<luis_> i dont know which version it is, just bought it from cvs. It comes with Windows CE, all i want is to get rid of it and install some version of linux on it
<dcordes> tmzt: connection got cut and can't login again
<dcordes> a pity people have such short attention span
<dcordes> it would have been interesting to discuss luis_' wince device in #htc-linux
<dcordes> http://digitalgadgets.com/netbooks/7-in-netbook.htm
<dcordes> hm magic rootstock random freeze
<dcordes> Unpacking humanity-icon-theme (from .../humanity-icon-theme_0.5.3.2_all.deb) ...
<dcordes> tmzt: it might be better to use your method and start off with the minimal image..
<dcordes> it's hopeless waste of time to try making a desktop or netbook image with rootstock
<dcordes> good night
#ubuntu-arm 2011-11-28
<punxos> Hi
<ppisati> ogra_: do i remember misremember, or does the preinstalled image resize during the first boot?
<ogra_> it does
<ogra_> it resizes, does some config bits and then does an auto-reboot
<ppisati> ogra_: but there's no output on console
<ogra_> on which image ?
<ppisati> ogra_: previously i remeber something was written out
<ppisati> preinstalled oma3
<ppisati> omap3
<ogra_> desktop images write to the splash only
<ogra_> its just the server image that writes to console
<ppisati> ok
<ogra_> what are you installing, desktop ?
<ogra_> you will need a monitor for that, else you cant use oem-config on the second boot
<ppisati> ogra_: saw it
<ogra_> :)
<ppisati> ogra_: actually, the image from friday still had a 3.0.x kernel (and thus broken usb) but the video was ok
<ppisati> ogra_: 28nov image has kernel 3.2.x
<ppisati> ogra_: so good usb but my monitor says "out of range freq"
<ppisati> ogra_: now i wonder if it's a "new feature" of the new kernel or any other new component
<ogra_> we didnt change anything in arm land yet
<ogra_> the build should be identical to oneiric, modulo the general package updates we inherit
<ppisati> all the pkgs are still O? at least the kernel is not
<ogra_> (which indeed could be at fault)
<ppisati> btw, this on a xm rev c
<ogra_> no, thats what i mean ... there were package updates ... but no specific arm changes yet
<ppisati> ok
<ogra_> does linaro have rev C's ? they probably know what could cause it
<ppisati> the problem with the rev c was usb only
<ppisati> but has been fixed upstream
<ppisati> what i discovered this morning
<ppisati> is that we lost video output now
<ogra_> right, which could be either xorg or the kernel DSS driver
<ppisati> right
<ogra_> and to my knowledge nothing in xfbdev (which is our default Xserver on all arm images) has changed
<ogra_> to me it smells like an EDID issue
<ppisati> we dropped one patch in 3.2
<ppisati> but according to the maintainer, it was not needed anymore
<ogra_> well, i know rsalveti tried to get some EDID stuff upstream for omap3 since a while, that might have landed and be broken or something similar
<ppisati> is there a deafult user before oem-config completes?
<ogra_> no
<ogra_> do you get the out of sync message only when x starts or already before
<ppisati> sorry
<ppisati> during the boot, i get a yellow/orange screen
<ppisati> then during boot it says "no signal detected"
<ppisati> and it turns off
<ppisati> and gitweb on kernel.ubuntu.com is slow...
<ogra_> orange screen ?
<ogra_> nothing in ubuntu creates orange screens
<ogra_> are you sure there is no nand on that XM ?
<ppisati> it's a brand new xm
<ogra_> (which carries something like an angstrom u-boot ... (which in turn uses orange screens on u-boot))
<ppisati> btw, we dropped this oneiric/master @ 1704827e32f20204b6af9b8143aff226211ac270
<ogra_> i know theoretically there shouldnt be nand, but i know that a handfull XMs were producsed with it
<ppisati> "UBUNTU: ARM: Adding regulator supply for vdds_sdi."
<ogra_> hmm
<ppisati> http://paste.ubuntu.com/752363/
<ppisati> here's my boot
<ppisati> i added ttyO2 to /etc/init
<ppisati> now let me add a root user
<ogra_> OMAP3 Beagle board + LPDDR/NAND
<ogra_> there you have your issue
<ppisati> wait
<ppisati> with a 3.0.x kernel the video output was working
<ogra_> it doesnt even seem to load the boot.scr
<ogra_> looks like you boot from NAND
<ppisati> no no
<ppisati> it loads boot.scr
<ogra_> or no, it actually reads boot.scr a bit later
<ppisati> "Loaded script from boot.scr"
<ogra_> *after* it complained it couldnt find it
<ogra_> *** Warning - readenv() failed, using default environment
<ogra_> it definitely uses the wrong x-loader
<ogra_> our x-loader comes from the u-boot package since oneiric, it would have the same build data
<ogra_> which it apparently doesnt
<ogra_> there must be a key combo to enforce loading from SD ...
<ppisati> "Texas Instruments X-Loader 1.5.1 (Jul 15 2011 - 21:29:14)"
<ppisati> is it wrong?
<ogra_> try holiding down the user button wuring boot and see
<ogra_> *during
<ppisati> let's try
<ogra_> you should never see an organe screen on an ubuntu boot
<ogra_> *orange
<ppisati> but that's when i press the reset button/during the bootloaders
<ppisati> perhaps is an artifact of the reboot
<ogra_> i doubt that
<ppisati> (some regs have some values etcetc)
<ppisati> btw
<ogra_> i would think its x-loader
<ppisati> can you confirm me the X-loader version?
<ogra_> should be from the same build as u-boot
<ogra_> they come from the same source package
<ogra_> and your u-boot clearly states it finds NAND
<ppisati> no
<ogra_> hmm, though it matches the actual last x-loader upload
<ppisati> it says
<ppisati> "NAND:  0 MiB"
<ogra_> i wonder why ...
<ppisati> IMO the bootloader part is correct
<ppisati> let's see if i have an O installation on anotther sd
<ogra_> but you see orange if the board powers up ...
<ppisati> i can try that kernel
<ppisati> on the other installation
<ppisati> true
<ogra_> and the only thing loaded first is x-loader
<ppisati> ok
<ppisati> now i resetted the board
<ppisati> and pressed the button
<ppisati> i'm at the
<ppisati> u-boot prompt
<ppisati> and i've the yellow/orange screen
<ppisati> so
<ogra_> hmpf
<ppisati> it loaded x-loader and u-boot only
<ppisati> let me try with a cold boot
<ppisati> ah!
<ppisati> with a cold boot
<ppisati> no orange screen
<ogra_> aha
<ppisati> the screen stays off
<ppisati> no matter how many times i reset it
<ppisati> if i stop the board at the u-boot promp
<ppisati> t
<ppisati> the screen is off
<ppisati> first boot completed
<ppisati> screen is still off
<ppisati> reset
<ogra_> hmm
<ogra_> auto-reset ?
<ppisati> and there we go
<ppisati> orange screen
<ppisati> no, reset button
<ppisati> let me try thus kernel on O
<ogra_> k
<fisuk> is there a bug in video hw decode on oneiric or am i doing something wrong (custom rootstock + omap4-extras installed + totem as a video player) as totem crashes from time to time (segfault) and there's strange artefacts displayed on the screen?
<fisuk> video scaling seems to be a bit off too..
<fisuk> (on pandaboard that is)
<ogra_> rootstock shouldnt be used anymore
<ogra_> use a properly built image
<fisuk> so like, ubuntu core?
<ogra_> ubuntu-aerver if you want without desktop, ubuntu-desktop if you want with desktop
<ogra_> ubuntu-core if you know how to build images
<ogra_> -core is just a base for building your own stuff if you exactly know what you are doing, its completely unconfigured and doesnt even have things likd dhcp support by default
<fisuk> hmm, alright
<fisuk> well, i'll give the server a spin and if it feels too bloaty, i'll go for the core... thanks for the pointers.
<rsalveti> ogra_: edid should be in for 3.3, at least robclark said it's now at staging-next
<rsalveti> we could backport it easily I believe, as it'll only affect staging
<rsalveti> ppisati: but I don't believe we tested beagle with 3.2 upstream yet
<ppisati> ok
<ppisati> when you test it, tell me if get video out
<rsalveti> ppisati: is this issue happening with the current precise tree?
<rsalveti> ppisati: will give it a try here
<ppisati> yes
<ppisati> P/master
<ppisati> i was trying the preinstalled image from 28Nov
<ppisati> when i noticed that my screen was blank
<ppisati> ogra_: seems it's the 3.2 kernel
<ogra_> aha
<ppisati> ogra_: installing it on a brand new O/omap3
<ogra_> intresting that it gets orange
<ppisati> ogra_: kills the video
<ppisati> wait
<ppisati> it's orange even in O
<ppisati> what is strange is that
<ppisati> X starts
<ppisati> but my mionitor stays off
<ogra_> hmm, sounds like EDID again
<ppisati> but rsalveti said it didnb't enter mainline
<ppisati> now i'm uptading it
<ogra_> but it could also be that it is caused by the resolution we set on the cmdline
<ogra_> you could tzry to mangle boot.scr
<ppisati> well
<ppisati> uhm
<ppisati> actually IMO
<ppisati> X thinks is connected to something else
<ppisati> else it wouldn't start
<ogra_> it uses /dev/fb0
<ogra_> however that was set up by the kernel
<ogra_> it doesnt mangle anything and just adopts the existing data the kernel has set
<ogra_> (resolution, frequency etc)
<ppisati> i'll try to see if there's any difference in dmesg
<ogra_> yeah
<ppisati> and X log
<ogra_> yup
<ogra_> if its just the splash, it could well be a plymouth bug
<ppisati> [    3.394592] omapfb omapfb: no driver for display: dvi
<ppisati> [    3.394622] omapfb omapfb: cannot parse default modes
<ppisati> uhm
<ogra_> aha
<rsalveti> ppisati: iirc there's a new dvi driver, or something like that
<rsalveti> maybe it's just not enabled at the config
<rsalveti> not sure
<ogra_> i'm still stunned that it turns your screen orange :)
<rsalveti> ogra_: that's u-boot
<ogra_> evil, can we disable that =
<ogra_> ?
<rsalveti> ogra_: probably, any reason to disable it?
<ogra_> its orange !
<rsalveti> ogra_: haha, guess we can change to any other color
<rsalveti> ideally it'd be nice to have a picture of something there
<ogra_> the ubuntu splash
<ogra_> ;)
<infinity> Or just the same purple that the Ubuntu plymouth theme uses.
<infinity> Since grub does that too.
<ynezz> but I've heard, that orange color shows you better the crappy color reproduction of your LCD :p
<Wellark> ogra_: thanks for the invitation :)
<rsalveti> infinity: yeah, should be easy to change it to purple
<rsalveti> ppisati: ogra_: cool, just noticed my edid changes at the dvi driver was applied at the kernel
<rsalveti> that's why, we have a new panel now
<rsalveti> panel-dvi.c
<rsalveti> that's based on my implementation
<rsalveti> that in theory probes and parses the edid
<rsalveti> ppisati: I believe it's just a config change here, I'm building the kernel now and will check in a few
<ppisati> ah
<ppisati> i was just reverting some changes in omapfb
<ppisati> "OMAPFB: find best mode from edid"?
<ppisati> this one?
<ppisati> rsalveti: ^^
<rsalveti> ppisati: I don't believe we need to revert anything
<rsalveti> ppisati: panel_dvi is =m
<rsalveti> should probably be =y
<rsalveti> and generic_panel should be disabled
<rsalveti> that's my guess
<ppisati> saw it
<ogra_> rsalveti, and i suspect we should drop the hardcoded resolution from boot.scr
<ogra_> :)
<rsalveti> ogra_: probably :-)
<ppisati> rsalveti: yes it works
<ppisati> with panel_dvi=y
<rsalveti> ppisati: awesome, and should also be working with edid
<rsalveti> ppisati: try removing the cmd line that forces a resolution
<ogra_> awesome that this didnt break it :)
<ppisati> ok, pushed
<ppisati> so, you want me to drop:
<ppisati> "omapfb.mode=dvi:1280x720MR-16@60"
<ppisati> right?
<rsalveti> ogra_: https://blueprints.launchpad.net/u-boot-linaro/+spec/spl-enablement-for-omap3
<rsalveti> ppisati: yes
<ogra_> rsalveti, awesome !
<ppisati> yes, it works
<rsalveti> ogra_: https://blueprints.launchpad.net/u-boot-linaro/+spec/investigate-common-spl-for-omap3-and-omap4
<rsalveti> ppisati: great!
<rsalveti> ogra_: seems you can now remove the omapfb cmd line from the kernel then
<ogra_> rsalveti, well, once that kernel is in
<ogra_> or that config change rather
<rsalveti> ogra_: well, the current kernel doesn't work anyway
<ogra_> yeah
<ogra_> not a good start of the milestone freeze :/
<rsalveti> at least we found the fix at monday
<ogra_> ppisati, do you see any chance there will be a kernel upload today or tomorrow with that fix ?
<ppisati> ogra_: hope so
<ogra_> k
<ogra_> we need to tell GrueMaster to hold off on omap3 testing
 * GrueMaster holding off.  (will read backscroll to get rest of what he is holding off from).
<ogra_> broken display driver
<ogra_> you might be able to test server omap3 if you feel like ... but that will also need re-testing for the new kernel
<micahg> suihkulokki: did you try to just disable webrtc w/out reenabling system vpx for chromium?
#ubuntu-arm 2011-11-29
<suihkulokki> micahg: yes, remoting still needs vpx
<micahg> suihkulokki: right, but there's an internal libvpx that chromium builds, is there a guide for me to set up a cross-compile env to test this with?
 * micahg would love to be able to fix armel on amd64
<suihkulokki> micahg: for whatever reason the internal vpx is not happy to build on armel
<micahg> suihkulokki: ok, I'll try to fix that then, I'd prefer to use internal libvpx since chromium's minimum version will change through the stable release
<mira|AO> hi, Iâm a bit concerned about the armel build of mksh and would be grateful if one of you running precise could:
<mira|AO> install mksh_40.3-1_armel; cd /tmp; cp /usr/share/doc/mksh/check.* .; gzip -d check.t; gzip -d check.pl; perl check.pl -s check.t -p /bin/mksh-static -v -C smksh,binsh,convfds,no-histfile 2>&1 | tee log
* ogra_ changed the topic of #ubuntu-arm to: Ubuntu ARMv7 Discussion & Development | https://wiki.ubuntu.com/ARM | Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Get oneiric while it's hot ! http://cdimage.ubuntu.com/releases/11.10/release/ | Logs at http://irclogs.ubuntu.com/ | armhf builds are running
 * ogra_ finds it worth to put armhf in the topic
<SidH_> hi, rootstock is deprecated right?
<rsalveti> SidH_: yes
<rsalveti> you can still use it, but we're not planning on fixing the issues on it anymore
<rsalveti> live-build should be used instead
<SidH_> Can I add a note to https://wiki.ubuntu.com/ARM/RootfsFromScratch about the deprecation
<rsalveti> but I still need to blog about properly enabling live-build to replace rootstock
<SidH_> Similar to the Rootstock page itself?
<SidH_> Ah.
<SidH_> I tried the -core image on my DaVinci board today
<ogra_> SidH_, once rsalveti's blog post is out i'll kill the upstream project and ask for package removal from the archive
<rsalveti> SidH_: yeah, we'd need to update this wiki with the instructions to use live-build instead
<SidH_> Thanks!
<rsalveti> yeah, planning to make it available this week
<ogra_> no hurry :)
<rsalveti> now that we're off the release week madness
<rsalveti> ogra_: and how is alpha 1 going?
<SidH_> I'm basically trying out ubuntu-arm on my board and wanted to follow the existing instructions
<rsalveti> ogra_: tested the kernel for omap 3 here yesterday and it's working fine with the config change
<ogra_> not to bad, the omap3 fix made it in ... i havent tested ac100 yet, panda should be fine
<rsalveti> ogra_: cool
 * ogra_ hasnt heard anything bad from GrueMaster either 
<rsalveti> NCommander: help on the packaging side for xbmc should be useful, for sure :-)
<rsalveti> NCommander: one thing aviksil is looking at is trying to integrate the gstreamer patches
<NCommander> rsalveti: well landing them into the Ubuntu packaging isn't that hard,then its just a matter of making a seed materialize
<rsalveti> then we can properly use the hw decode support at panda
<GrueMaster> ogra_: Haven't done any recent testing as I have been fully engaged in getting the qrt kernel tests running for SRU testing.
<ogra_> yeah, i thought so
<ogra_> well, shouldn be all solved on omap3 now
<GrueMaster> I do plan on testing some current images today (barring interrupts).
 * ogra_ stops interupting immediately
<GrueMaster> heh
<doko> NCommander, ogra_: could somebody look at the ruby1.9.1 test failure on armel?
<robbiew> NCommander: you see this -> http://lists.linuxfoundation.org/pipermail/virtualization/2011-November/018995.html
<NCommander> robbiew: that's drool worthy
<NCommander> robbiew: even thoughour support for Xenis 'shakey' at best
<robbiew> yeah
<NCommander> I'd love to know how they got A15 hardware though ...
<infinity> NCommander: it was vexpress, I assume entirely emulated?
<robbiew> infinity: yep
<infinity> NCommander: Though they gave kudos to ARM, so maybe they actually have a real vexpress A15 sitting on their desks.
<robbiew> "...the port is already capable of booting a Linux 3.0 based virtual machine (dom0) up to a shell prompt on an ARM Architecture Envelope Model, configured to emulate an A15-based Versatile Express.", so looks like it's all emulated
 * infinity nods.
<NCommander> Oh, d'oh
<GrueMaster> Sounds almost like a xilinx gpgpu emulating an a15.
<jjardon> Hi, what is the difference between arm-linux-gnuabi and arm-unknown-linux-gnuabi targets?
<infinity> jjardon: (Both of those are missing an "e")
<infinity> jjardon: And nothing.  The -unknown- is a vendor string, and Debian/Ubuntu don't set it.
<infinity> jjardon: RedHat sets it to -redhat-, for instance.
<jjardon> infinity: yeah, you are rigth. I asked because my arm board shows arm-linux-gnuabi and my cross-compiler gcc arm-unknown-linux-gnuabi
<infinity> gnueabi, surely.
<infinity> Anyhow, arm-linux-gnueabi == arm-unknown-linux-gnueabi == arm-*-linux-gnueabi (the latter being how it's often represented in autotools and such)
<jjardon> infinity: ok, thanks!
#ubuntu-arm 2011-11-30
<NCommander> GrueMaster: any luck with that image/
<GrueMaster> Haven't rechecked.  Just automating core image tests for all 3 arches.  Running it now through jenkins.
<GrueMaster> Ok, it was waiting for me to nudge it past restricted.
<GrueMaster> running now.
<GrueMaster> fail.
<GrueMaster> Jan  1 02:25:00 base-installer: info: could not determine kernel flavour
<GrueMaster> This is telling:  Jan  1 01:58:17 base-installer: warning: Unknown armel subarchitecture 'omap4'.
<WaltherF1> Um, the latest I checked at raspberrypi.org, the final version is using Broadcom BCM2835, ARM11 compatible - isn't that one of the "newer" versions, that should be supported by Ubuntu?
<infinity> WaltherF1: Unless something's changed, the Pi is armv6, and we build for v7.
<WaltherF1> infinity: They published a new graphic for the final version, http://www.raspberrypi.org/wp-content/uploads/2011/11/Raspi-Model-AB-Mono-1.png
<WaltherF1> infinity: and it exclusively states ARM11
<infinity> WaltherF1: ARM11 = ARMv6
<WaltherF1> ah, okay, sorry for the confusion
<WaltherF1> ...and btw, imo that's not a neat way of arranging your versioning -.-
<WaltherF1> (not your fault!)
<infinity> http://en.wikipedia.org/wiki/List_of_ARM_microprocessor_cores
<infinity> And yeah, it's confusing.
<ogra_> send your thanks to ARM for that kind of crappy versioning :)
<infinity> The Cortexes continue the confusion with going from A8 to A9 to A7 and A15...
<ogra_> yeah
<ogra_> at least A7 will then be v7
<infinity> Hah.
<lilstevie> heh
<WaltherF1> duh, at least ubuntu is sensible with yy.mm
<ogra_> janimo, oh, btw, having the ac100 kernel built for el as well as hf would be nice
<infinity> ogra_: Kernels will come.
<ogra_> WaltherF1, well, but we use funny names too :)
<infinity> I'll bug people more insistently when the archive is actually installable.
<ogra_> infinity, that kernel will need jani or me touching it ... its not maintained by the kernel team
<lilstevie> ogra_: el and hf?
<infinity> ogra_: I know.  Or me. :P
<ogra_> indeed :)
<infinity> lilstevie: armel and armhf.
<lilstevie> kernels shouldn't have that issue
<lilstevie> infinity: yeah I am aware
<infinity> lilstevie: The kernel needs to exist in the hf archive.
<ogra_> lilstevie, but you want an armhf .deb ;)
<infinity> Which means, sadly, building it twice.
<lilstevie> mer guys assured me that one kernel should be universal
<infinity> (Or building it as arch:all, but we really don't need ARM kernels on powerpc...)
<ogra_> its all about dpkg ... not actually the binary
<lilstevie> ah
<infinity> lilstevie: Identical build.  Just needs to be in both _armel.deb and _armhf.deb form. :P
<lilstevie> kinda crappy system
<ogra_> we could as well just cp them on ports.u.c :P
<infinity> Well, dpkg could handle it fine, to be fair.
<infinity> We could do multiarch kernels.
<infinity> And should, eventually.
<infinity> But we'd need some installer mangling to make that work.
<lilstevie> ah
<infinity> The path of least resistance for now is just two builds.  It's not world-ending.
<infinity> Just a waste of 4 hours of a panda's time.
<lilstevie> heh
<ogra_> and given that one of the arches will go away anyway ...
<lilstevie> yeah
<infinity> ogra_: I kinda want to rebootstrap armel as v4T as a community project (and maintain bi-arch/multi-arch with it)... Is that wrong? :P
<infinity> I'd have to do it out of work hours, but I'm quite tempted, to be honest.
<ogra_> well, the pi people would love you forever for that :)
<lilstevie> infinity: not really, that would solve the problems with all these *plug devices wanting ubuntu
<ogra_> i would help :=
<ogra_> :)
<WaltherF1> now this sounds good, I'd be eager to help with all my knowledge as well
<lilstevie> I would donate CPU time on my trimslice as a builder if that would help
<ogra_> is theere actually much work to do apart from changing compiler flags and do a complete rebuild ?
<ogra_> (and getting approval for the resource costs indeed)
<infinity> ogra_: And back out any braindead patches we have that assume thumb/vfp/etc.
<ogra_> well, just re-roll debian then
<infinity> ogra_: Basically, revert to pure Debian compat for armel.  Which shouldn't be too hard.
<ogra_> yeah
<davidm> infinity, but why bother duplicating Debian, it's already there?
<infinity> The upshot is that we can do it on v7 hardware and just cheat.
<infinity> davidm: Because we get a TON of people who are grumpy when we say "use Debian for you < v7 device".
<ogra_> davidm, there is no unity :)
<infinity> davidm: And when our official v7 solution becomes armhf, it might be a nice community service to offer a baselive v4T again.
<WaltherF1> Gentlemen (and ladies?), I appreciate this. Thank you.
<ogra_> indeed totally unsupported etc
<infinity> WaltherF1: Nothing to appreciate yet. :P
<infinity> WaltherF1: I need to get a lot of people to agree to my insanity before it could ever happen.
<lilstevie> infinity: heh
<infinity> WaltherF1: (And the official answer for now on the Pi is, indeed, "use Debian")
<davidm> and I suspect with the current lack of HW it's not going to happen
<WaltherF1> infinity: But hey, I got you convinced to my insanity already, isn't that a start :P
<ogra_> WaltherF1, even if it would happen that would be in a year from now or so
<infinity> davidm: Get me one 4U Calxeda box and we can build 4 arm* ports and keep up. :P
<WaltherF1> yeah yeah, i'm not going to spoil this anywhere... But I can guarantee, (if)/when you'll announce the support officially, internet will shit bricks
<infinity> WaltherF1: It would never be "official".
<infinity> WaltherF1: It would be as unofficial as our powerpc port (which people keep trying to drop...)
<infinity> So...
<infinity> I wouldn't hold your breath, is the take-home message. ;)
<infinity> Still, I'd like to do it.
<ogra_> we should also add nslu2 images back :P
<ogra_> once we have such a prot
<ogra_> *port
<xranby> sneaky.. so when fedora moves to armhf we grab the legacy armv5 armel turf?
<ogra_> xranby, its just a weird idea by a sleep lacking developer :P
<infinity> xranby: Fedo--who?  Doesn't evern v5 user run Debian? :)
<infinity> s/evern/every/
<xranby> at least some old fedora verson was preinstalled on the openrd boards
<xranby> also some netgear NAS  like the Stora are based on a locked down fedora
<xranby> infinity: but.. yeah.. i agree  I do run debian on my openrd machines and on my Stora :)
<robbiew> NCommander: ping
<robbiew> infinity: ping...any idea when we can expect to have an armhf image for folks to test out?
<infinity> robbiew: Desktop won't be for quite a while (hard to estimate while build-deps are being unsnagged), server might be doable (with some bits missing) in a week or so?
<infinity> robbiew: Very hand-wavy at this point, hard to commit until I can get a good overview of what I still need to manually bootstrap.
<robbiew> ack
<infinity> robbiew: Plus, I'll need to force some server bits to the front of the queue to make that estimate. ;)
<robbiew> infinity: cool, thx
<robbiew> heh
<robbiew> infinity: looks like the ARM Supercomputer folks are willing to testdrive our bits
<robbiew> so the sooner the better ;)
<infinity> robbiew: I'd like to testdrive theirs too!
<infinity> (Man, that sounds bad)
<robbiew> I'm working on that
<infinity> robbiew: I'll see what I can do about reordering and jamming some more stage-2 bootstrap bits in for server dep loops.
<infinity> robbiew: Of course, we won't have installable images for those folks (as I assume they use kernels we don't ship), but I also assume they're smart enough to figure out how to install minimal chroots and go from there.
<robbiew> infinity: yeah...given they've been using Ubuntu already...I think so :P
<infinity> robbiew: Feel free to keep giving me gentle prods over the next week or two.  I'll see what I can do about delivering most of server-ship.
<infinity> (Hey, you already have MySQL, we're done, right?)
<doko> infinity, robbiew: a debootstrappable buildd chroot would be appreciated as the first step ;-P
<infinity> (Right?)
<infinity> doko: Yeah, yeah.  Working on it.
<doko> couldn't resist ...
<robbiew> infinity:cool...who should I talk to about producing an ARM HPC kernel for them...is that you all or #ubuntu-kernel folks
<infinity> doko: You can cheat and debootstrap --minbase from http://people.canonical.com/~ubuntu-archive/armhf/ for now, add ports.u.c to the sources.list, and install build-essential.
<robbiew> They need kernel scheduler and parameters tuned for single-threaded execution, as there is no user interaction or time-sharing in an HPC platform
<infinity> robbiew: Well, I assume it would be targetted specifically at their hardware as well.  You could talk to davidm about it.  I'm fairly sure it won't be his team that ends up doing the work, but he'll know who should. :P
<infinity> doko: --variant=minbase, that is. But you know what I mean.
<infinity> doko: But I'll get --variant=buildd working from ports fairly soon.  Need a kernel and a few other bits.
<robbiew> infinity: ack, thx
<doko> infinity, minbose is supposed to work?
<robbiew> infinity: yeah...could be something done as part of a Canonical/BSC relationship
<infinity> doko: minbase works from people.
<doko> ahh
<infinity> doko: Probably not from ports yet.
<infinity> doko: buildd would theoretically work from people too, except my stage-2 archive doesn't take overrides into account, so sections/priorities are wrong, and debootstrap has a bit of a hissy fit about the whole deal.
<infinity> doko: But yeah, if you want to play, minbase from people, add ports at the top of sources.list (and keep people), install build-essential, have fun.
<ogra_> well, shouldnt -core be buildable already ?
<ogra_> we could probably make A1 with it ;)
<ogra_> (for hf that is)
<infinity> ogra_: Not yet.
 * infinity tests this statement.
<ogra_> if minbase and apt work i would have guessed it should be buildable
<doko> infinity, did you ever get a reply from apw about linux-libc-dev built from separate source?
<infinity> Note that I said to debootstrap minbase from my stage-2.
<infinity> Not from the archive. ;)
<ogra_> (which i would expect to be reqs for the buildd setup)
<ogra_> ah
<ogra_> that one i missed indeed :)
<infinity> doko: linux-libc-dev is buildable out-of-band with DEB_STAGE=stage1
<infinity> doko: Works well enough for bootstrapping.
<infinity> ogra_: Yeah, minbase is still missing a few bits in the archive.  Will sort it.
<infinity> Oh, or not just yet.
<infinity> Need ruby1.9 to build libselinux.
<infinity> La la la.
<infinity> Sorting slowly. ;)
<ogra_> no hurry, i wasnt actually serious about A1 anyway
<doko> looks like the bootstrap is stalled now, universe packages start building
<NCommander> robbiew: pong
<infinity> doko: I'm revisiting some snags.
<robbiew> NCommander: nevermind...all sorted ;)
<NCommander> robbiew: k :-)
<robbiew> NCommander: got another question for ya...any reason why hdf5 isn't tagged for armhf builds? ->    https://launchpad.net/ubuntu/precise/+source/hdf5
<robbiew> hdf4 is, but our supercomputer friends in barcelona would like hdf5 :)
<NCommander> robbiew: its probably in P-a-s
<NCommander> looking
<ogra_> it probably simply missesw armhf in debian/control
<ogra_> *misses
<infinity> What ogra_ said.
<NCommander> ogra_: any all
<infinity> It's not P-a-s.
<NCommander> hrm, no its got a armhf build record
<NCommander> robbiew: https://launchpad.net/ubuntu/+source/hdf5/1.8.4-patch1-3ubuntu1/+build/2963282
<infinity> Oh, then it just needs to build. :P
<robbiew> ah
<robbiew> cool...nevermind :)
<NCommander> robbiew: always use the source overview page to look at what builds are doing what where: https://launchpad.net/ubuntu/+source/hdf5
<ogra_> robbiew, http://qa.ubuntuwire.org/ftbfs/primary-precise-armhf.html might also be intresting for you in case you look for failed builds (not actually instresting at this stage of the bootstrap but will be soon)
<infinity> doko: We have a fair few packages that need -lm fixes.  You could queue those up for uploads right after the freeze is over, if you're feeling helpful. ;)
<robbiew> NCommander: thanks...I **thought** I did :/
<NCommander> robbiew: you were looking at the percise version page. LP's URLs for finding stuff are kinda irritating
<infinity> robbiew: having the release name in the URL is a drastically different page.  Annoys me to no end.
<robbiew> indeed
<NCommander> +1 infinity
<infinity> (Try having the release name in a bug URL and see how that screws with your head)
<infinity> Like, being unable to target things, etc.
<doko> infinity, hmm, new -as-needed ftbfs?
<infinity> doko: No, it was the "something used to needlessly link against libm and doesn't anymore" thing.
<infinity> doko: Remember that landed late in the oneiric cycle and then seb128 rapidly reverted it?
<doko> ahh, the seb128^Bgnome mess
<infinity> doko: Well, it's landed for good now.
<infinity> doko: https://launchpad.net/ubuntu/+source/gnome-desktop/1:2.32.1-0ubuntu6/+build/2962501 <-- For example.
<infinity> I'm working on the "stuff that's FTBFS due to changes in if_packet.h" failures right now.
<doko> ahh, like klibc?
<infinity> doko: klibc, iproute... I'm sure I've seen a couple more.  Will comb.
<infinity> Of course, I also need a nap at some point.
<infinity> python distracted me last night.
<doko> ctypes?
<infinity> ctypes is hilariously broken.
<infinity> Yeah.
<doko> lool sent a patch
<infinity> Yeah, I'm building with it.
<infinity> But that's just papering over awful code.
#ubuntu-arm 2011-12-01
<doko> infinity, something is f*cked, python2.7 depends on libsfgcc1
<infinity> doko: Err, does it?
<infinity> doko: Just now?
<infinity> doko: Grr.  My build of 5ubuntu1.1 must have been in a dirty chroot.  Though, the part where it picked up that dependency is worrying.
<infinity> doko: Yeah, confirmed that I built it in a chroot with gcc-multilib installed.  But ouch that it didn't do the right thing. :/
<infinity> doko: Erk, and gcj-4.6 depends on libsfgcc1 ...
<infinity> doko: Looks like it's dpkg-shlibdeps misbehaving.  The dependencies are spurious (the packages in question aren't actually linked against libsfgcc1), but once I come up with a sane fix, we'll need to do no-change rebuilds to drop the dep.
<doko> infinity, wondering why, because the sf libraries shouldn't be installed for the python2.7 build
<infinity> doko: They were for my local python build.  That's fixed.  But other packages suffer similar issues (like gcj, for instance).
<infinity> doko: Working on fixing dpkg-shlibdeps so it stops happening.
<infinity> doko: But other than the spurious dep (which is annoying, obviously), it's harmless.
<ogra_> infinity, https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview#Ubuntu_ARM does that look ok to you ?
<ogra_> (anything i should add like: contact the ubuntu-arm team if you encounter probs with your package builds etc ... )
<infinity> ogra_: Sounds reasonable (including the blurb)
<ogra_> k
<jamespage> morning
<jamespage> am I correct in thinking that Ubuntu support armv7 upwards only?
<ogra_> yes
<jamespage> OK; and by default do we compile thumb support (sorry if wrong terminology)?
<ogra_> thumb2, yes
<jamespage> ogra_, great - that validates my thinking on a ftbfs on libv8 then
<jamespage> thanks
<marcompile_panda> Hello, is there a way I can recompile the kernel I'm running right now (with the same version and config) without fetching it from git?
<ogra_> marcompile_panda, install build-essential and fakeroot, then apt-get source linux ...cd into the folder where it was unpacked, run dpkg-buildpackage -b -rfakeroot in that folder
<infinity> ogra_: apt-get --only-source source linux, actually.
<infinity> Or you end up with meta. :P
<ogra_> oh, indeed !
<infinity> (And for panda, probably "apt-get --only-source source linux-ti-omap4"
<infinity> )
<infinity> And then, for added fun, "apt-get build-dep linux-ti-omap4"
<ogra_> ah, i missed the panda, yeah
<ogra_> are there actual build deps ?
 * ogra_ never needed that 
<infinity> Should be some that aren't build-essential.
<infinity> Like kernel-wedge.
<ogra_> i'm not sure it uses that if you dpkg-buildpackage it
<ogra_> i definitely dont have it installed here and have built multiple kernel packages on this machine before
<ogra_> marcompile_panda, do change the config use debian/rules editconfigs
<ogra_> (assuming you want to actually change it)
<rsalveti> janimo: https://blueprints.launchpad.net/linaro-ubuntu/+spec/push-multiarch-changes-for-cross-precise
<rsalveti> janimo: to make firefox cross build working with multi-arch at precise
<marcompile_panda> ogra_, will try that. thank you
<ogra_> ********** ARM Team meeting starts in ~5 min in #ubuntu-meeting *********
<ogra_> ********** ARM Team meeting starts now  in #ubuntu-meeting *********
<Jcouture> Hi, I would like to know if it's possible to install Eclipse on an ARM infrastructure and also the JAVA SDK and JVM? Thank you! I'm looking to maybe buy a transformer prime and replace my netbook and my nook color.
<GrueMaster> Jcouture: AFAIK, yes.  I use jvm on arm for qa automation (jenkins slave).  Not sure on eclipse, but it "should" work.
<Jcouture> Ok, sry, I just closed my window by accident, didn't see if somebody answered me
<lilstevie> Jcouture: there is no guarentee that you will be able to run ubuntu on the prime straight up
<Netham46> Are there any tutorials for rebuilding a rootfs using whatever means is currently stable and supported?
<Netham46> Kinda sucks that they dumped rootstock support, it was so easy to use.
<GrueMaster> Netham46: We are working on new documentation.  Should have it ready in the next few weeks.  In the mean time, you can use our ubuntu-core images as a base.
<Netham46> GrueMaster, kk. Know where they are?
<GrueMaster> http://cdimage.ubuntu.com/ubuntu-core
<Netham46> Thanks.
<Sycro5> Hi, I'm using a Pandaboard to run Ubuntu and am having problems using the Bluetooth capabilities.  Are there drivers available to get BT running on the Pandaboard?  I can't find anything definitive online.
<GrueMaster> Sycro5: Which Ubuntu release?  Starting with Oneiric, the firmware should be there (not sure on natty off hand).
<Sycro5> well, I'm actually still using 11.04 at the moment, but I'm happy to upgrade to 11.10 if that will make a difference
<Sycro5> Here is the exact pre-built binary I'm using: http://omappedia.org/wiki/Prebuilt_ubuntu_binaries
<Sycro5> ...the Natty Narwal Netbook
<GrueMaster> Yea, looking at my natty system, I don't see the firmware there.
<Sycro5> what do you recommend then?
<GrueMaster> Oneiric/
<GrueMaster> I see the firmware on that image.
<GrueMaster> http://cdimage.ubuntu.com/releases/oneiric/release/ubuntu-11.10-preinstalled-desktop-armel+omap4.img.gz
<Sycro5> thanks a lot.  Can I upgrade to Oneiric using the update manager in Ubuntu, or do I need to re-partition my drive with this build?
<GrueMaster> You should be able to upgrade.  But it is much slower than pulling down a new image (if you are running on SD).
<Sycro5> Great, thanks!
<xenon_> hi all
<xenon_> what is the last stable release ubuntu for pandaboard ?
<xenon_> 10.04? 10.10 ? 11.04 ? 11.10?
<GrueMaster> http://cdimage.ubuntu.com/releases/oneiric/release/ubuntu-11.10-preinstalled-desktop-armel+omap4.img.gz
<xenon_> thanks
<GrueMaster> There is no support in 10.04, 10.10 was initial bring-up.
<xenon_> i have tested this version but it loops for configuration i can install it
<xenon_> i can't*
<GrueMaster> Yea, known issue.
<xenon_> there is no issue actually ?
<xenon_> :(
<GrueMaster> To work around it, when the installer loops back to the language selection,hit <ctrl><alt><F1>, log in as the user you created earlier, and type "sudo oem-config-remove && sudo reboot" (without quotes).
<GrueMaster> There is a timing issue with the SD card driver (I think).  Very hard to debug.
<xenon_> yes
<xenon_> thanks i'll test this issue
<GrueMaster> And Ubuntu-desktop image triggers  this very reliably.  Don't see it on ubuntu-server or kubuntu-desktop.
<xenon_> ok
#ubuntu-arm 2011-12-02
<therussianjig> is the OMAP4 build optimimized for an ARMv7 arch?
<lilstevie> therussianjig: ubuntu-arm is only built for the v7 arch
<twb> ubuntu only provides armv7 binaries AFAIK
<therussianjig> kk ty
<twb> lilstevie: btw you still ship ext[234] rootfs images, right?
<twb> lilstevie: if you run zerofree(8) on them they will compress better
<twb> http://paste.debian.net/147769/ -- dunno what the numbers mean, but I think it's saying that it *did* make your image more compressible :-)
<lilstevie> yes, ext4 images
<lilstevie> I will keep that in mind
<lilstevie> anything that brings the size down further makes my life easier
<twb> If you have just created a fresh image with e.g. genextimage it won't help much, but if you've an ext that has been lying around and have >>0 edits to it, then it should help
<twb> (I'm doing it now because I'm out of disk on my netbook so zerofree + xz -9e on the rootfs.ext's to save some space :-)
<lilstevie> well it is the omap image from ubuntus servers
<lilstevie> with some edits
<twb> Ah, I didn't know that, interesting
<twb> It'd be cool if you could just ship it as a .mod for a union filesystem, like morphos used to do :-)
<twb> i.e. you say "go download ubuntu's image, then apply my copy-on-write union"
<twb> Or even sexier, a bootloader than can access a /boot on .sq, because then you can just ship an xz-compressed .squashfs and DD it directly onto the disk.
<lilstevie> heh union is a pain
<lilstevie> and it isn't the bootloader that prevents access to boot
<lilstevie> it is the partition layout
<twb> Yes that too
<lilstevie> also
<lilstevie> the other day you said about the 360 s being loud?
<twb> The new ones, yes
<lilstevie> I got one yesterday
<lilstevie> whisper quiet
<twb> lilstevie: the PSU fan?
<twb> That is, the power brick
<lilstevie> yeah, whole thing
<twb> Huh.
<lilstevie> barely makes a sound
<lilstevie> it is a corona board though
<lilstevie> not trinity
<twb> It probably doesn't help that I play games with the sound off/down, and my desk is basically designed to act as a sounding box for any speakers on it
<twb> lilstevie: dunno about corona/trinity business
<lilstevie> trinity is the 360 S initial revision
<twb> I use a 360 because its turnkey, i.e. I don't have to care about that
<lilstevie> corona is the newer lower power one
<lilstevie> heh
<twb> Is there a 1:1 correspondence between corona and having the newer kinect power doodad?
<lilstevie> no idea
<twb> Ah, no I think 360 S is that line, and within that is your two mobo models
<lilstevie> the corona has only been in production for the last 2 or 3 months
<lilstevie> it is going to be my only unhacked console :p
<twb>   7.5 %        93.8 MiB / 158.7 MiB = 0.591   224 KiB/s      12:04   2 h 30 min
<twb> ^^ xz -9e is chugging away on my image still :-)
<lilstevie> heh
<twb> Well, the actual command was "nice ionice -c3 xz -v9eM75%"
<twb> Which translates to be as slow and compressy as possible
<lilstevie> heh
<twb> Probably be faster to scp it to the buildd, compress it, scp it back :P
<lilstevie> lol
<twb> Incidentally you can also make a disk image sparse again using zum(1) from the perforate package
<lilstevie> and you can make it deceptively attractive with rum(1)?
<twb> NFI
<lilstevie> lol
<twb> lilstevie.geek.nz/ports/ubuntu.img (1/2)
<twb>   100 %     334.5 MiB / 2,048.0 MiB = 0.163   503 KiB/s    1:09:30
<twb> That's using plain xz, i.e. -6 or so not -9e
<twb> The other thing you could do, of course, is simply resize2fs -M it (reducing its actual size to its used size), and instruct users to do "resize2fs foo.img 2G" or whatever to grow it back out prior to use
<lilstevie> twb: seriously there is like <60MB extra in that image
<lilstevie> and I grow it on first boot
<twb> k
<twb> I'm just brainstorming here, you don't have to do what I say obviously
<fisuk> umm.. anyone else have this kind of behaviour when playing HD video https://groups.google.com/d/msg/pandaboard/HxKHj_n0d0g/b78ZmXhI6cMJ ?
<fisuk> (i'm not the same guy as the poster, but I too have that problem)
<suihkulokki> who was the one here asking about chromium and arm?
<ogra_> suihkulokki, micahg maintains it in ubuntu if you mean that
<ogra_> (and is still urgently looking for help to build it on arm)
<suihkulokki> micahg: if you want to try cross-compiling chromium, see: https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/ChromiumCrossCompile
<ogra_> i think he rather wants it to not FTBS in natvie builds first :)
<suihkulokki> yes, and with native builds it will take him 27h per build ;)
<ogra_> which is fine gievn that the binary didnt build since two releases now
<ogra_> would be good to have something more recent than 13.0.xx
<micahg> ogra_: I was hoping to cross compile in an attempt to fix the native builds faster than a +20hr iteration as suihkulokki pointed out :), my goal is that native builds should work though
<ogra_> yeah
<ogra_> i guess both is good
<micahg> yeah, if there's an arm person interested in keeping it building, I'll take patches that look sane
<ogra_> given that firefox still takes munites to start from SD ...
<micahg> otherwise, it's best effort on my part for ARM
<ogra_> vs seconds for chromium ...
<ogra_> *minutes
<micahg> ogra_: hmm...I would've thought omnijar fixed that, I guess we would need PGO to really make that happen
<ogra_> well, to be honest i havent touched FF since mid oneiric cycle anymore
<micahg> does the imx51 smartbook support armhf and would that make it perform faster?
<ogra_> at least for my day to day work on my ac100
<micahg> ogra_: ah, well, speedup is a focus of theirs now
<ogra_> all cortex-a8 and upwards should support armhf
<micahg> cool, will that speed build times though and performance?
<ogra_> the speedup you gain with hf is purely floating point stuff ... it wont improve i.e. disk IO
<micahg> ah
<ogra_> but things like pango and cairo should render lots faster
<ogra_> i heard something about 30% in best case scenarios
<dmart> JavaScript numeric data is mostly floating-point
<ogra_> yeah, that will speed up as well
<ogra_> its like 486DX vs 486SX :)
<ogra_> in case you still remember the difference
<dmart> I *had* an SX (and felt suitably cheated) ;)
<ogra_> heh
<taruti> any idea what could cause black areas form around letters in firefox and after a while X becoming unresponsive?
<taruti> on pandaboard that is
<dmart> accelerated graphics drivers would be the most likely cause
<taruti> so uninstalling those could help, will try
<dmart> You could try the most recent linaro LEB and see whether it makes a difference -- http://releases.linaro.org/11.11/ubuntu/leb-panda/panda-ubuntu-desktop.img.gz
<dmart> Maybe there are some issues which have been fixed in the meantime (depending on what you're using)
<ogra_> there surely are issues with 4460 boards and oneiric ... but i dont think many of these have been distributed yet
<ogra_> thermal issues ... not sure they would influence the graphics
<dmart> I'm not familiar with all the different OMAP4 variants -- is this a newer rev Panda, or a different board entirely?
<ogra_> newer panda ... next gen SoC
<ogra_> up to 1.2GHz (or was it 1.4 ...) etc
<dmart> ah, right
<ogra_> i know for the temp issues there are fixes in linaro ubuntu doesnt have yet
<ogra_> we'll get them with the next drop into precise
<taruti> ok
<ogra_> if you dont have a 4460 (which is likely) then that doesnt affect you though
<taruti> the older revision
<suihkulokki> micahg: the chromium 15 linked from the instrutions compiles both natively and cross (cross needs some libraries from the linaro staging).
<ogra_> awesome !
<ogra_> micahg, upload upload upload !!!!
<suihkulokki> micahg: so only thing needing fixing is reverting from system libvpx to the bundled one
 * ogra_ jumps up and down
<taruti> any idea whether two displays work simultaneously at the moment (dualhead)?
<ogra_> i dont think so
<ogra_> iirc the kernel only drives one of HDMI or DVI at once
<ogra_> though my info might be outdated
<taruti> googling reveals only people having problems
<ogra_> yep
<micahg> suihkulokki: great, thanks, unfortunately, I had a new build failure with .121 on amd64 that I have to fix first, but it's awesome that you got it working
<suihkulokki> micahg: I'll head asleep in few hours, email me if you bump into problems
<micahg> suihkulokki: thanks, I probably won't get to it until next week (cross compiling that is), but will let you know if I run into any issues
<ogra_> infinity, monday ... :)
 * ogra_ grins
<infinity> ogra_: Hrm?
<ogra_> -core
<infinity> ogra_: Oh, it would have been last night, but lamont kinda screwed up the setup on the buildd. ;)
<ogra_> ah, k *g*
<MrCurious> anyone know of a way to get pandaboard to run ubuntu11.10 at 1ghz instead of 800mhz?
<prpplague> MrCurious: should be able to force it to 920MHz as part of the frequency scaling
<MrCurious> i thought i read that it was disabled and locked at 800mhz in ubuntu11.10
<MrCurious> and the auto scaling was not yet working in 3.0 linux
<MrCurious> i am trying to catch up after a hiatus
<infinity> MrCurious: Where are you seeing it set to 800?
<MrCurious> read on a blog post
<MrCurious> bogomips on 11.10 is ~ 1500
<MrCurious> on 10.10 ~2000
<MrCurious> the blog post reasoned it to be 800mhz
<MrCurious> getting the url
<infinity> Oh, we seem to be lacking scaling in 3.0, so it gets stuck low.  Or some such unpleasantness.
<MrCurious> bit.ly/unRZt3 of fb.me/1bAMqhwYc
<infinity> That blog has the answer.
<infinity> Basically, wait for smartflex support.
<MrCurious> yeah
<MrCurious> i have active cooling for my board though, so was checking if it was a easy config to kick it up to 1ghz
<infinity> Not at runtime, since runtime support for changing the frequency is, well, not there.
<infinity> I suspect it wouldn't be much trouble to change it at the source level.
#ubuntu-arm 2011-12-03
<slangasek> checking for arm-linux-gnueabi-pkg-config... (cached) /usr/bin/pkg-config
<slangasek> thbbt
 * utlemming is away: Gone away for now
 * utlemming is back.
 * utlemming is away: Gone away for now
 * utlemming is back.
 * utlemming is away: Gone away for now
 * ogra_ sees ubuntu-core armhf and applauds infinity ...
<lilstevie> :)
<lilstevie> yay
<infinity> ogra_: Short-lived, mind you.  The buildd is acting up.
<ogra_> oh, still ?
<infinity> ogra_: It'll be doing dailies "later"... When lamont and I can diagnose the issue.
<infinity> ogra_: "still"?  It's a new buildd.
 * ogra_ just tried to read the webkit ftbfs log ..
<infinity> Don't worry about it.
<ogra_> smehow it exhausts my 512MB ram
<infinity> Unless you're an ELF wizard.
 * ogra_ doesnt think he is :P
<infinity> The webkit FTBFS (and a few others) is due to libicudata.so.48 being a braindead non-library with a hand-crafted (and incorrect) ELF header.
<infinity> I'll get to it soon.
<ogra_> yeah, just saw that in brtty
 * infinity nods.
<ogra_> i just dont get why the log is to big for my ram ...
<infinity> Cause web browsers suck.
<ogra_> heh, yeah
<infinity> 5MB log = 500MB to render.
<ogra_> plus caching ...
<infinity> There's a reason I have a laptop with 4G of RAM.
<infinity> Which is now not enough. :P
<infinity> Seemed good 4 years ago.
<ogra_> well, usually my 2G on the ac100 are enough, just slow
<ogra_> (due to swapping)
<infinity> Hrm.
<infinity> Sleep or fix icu, sleep or fix icu...
<ogra_> sleep !
<ogra_> if you can
<infinity> I probably can.
<infinity> I only slept 3 hours yesterday.  From 8am to 11am.
 * ogra_ tries a hf chroot from -core 
<infinity> So, I'm at 3 hours of sleep in the last ~48...
<ogra_> yeah, go to bed ...
<infinity> ogra_: Should work.  Let me know if it's broken.  I didn't actually check the manifest or anything.
<ogra_> tar acts up :(
<infinity> ...
<infinity> Let me check..
 * ogra_ tries again
<ogra_> but my system might be at fault after two times running out of ram for the webkit log
<ogra_> i should probably reboot to clear all caches
<infinity> tar was happy here.
<ogra_> hmm, untarring with sudo works
<ogra_> weird
<ogra_> ogra@horus:~/chroot-hf$ sudo chroot .
<ogra_> root@horus:/# dpkg --print-architecture
<ogra_> armhf
<ogra_> root@horus:/#
<ogra_> \o/
<ogra_> great, i have something to work in
<infinity> apt-get update and upgrade work, I call it a success.
<infinity> build-essential won't work for you.  No linux-libc-dev.
<infinity> Let me fix that for you. :P
<ogra_> no !
<ogra_> go sleep !
<infinity> It's 2 seconds to give you a link. :P
<ogra_> its saturday
<ogra_> k
* infinity changed the topic of #ubuntu-arm to: Ubuntu ARMv7 Discussion & Development | https://wiki.ubuntu.com/ARM | Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Get oneiric while it's hot ! http://cdimage.ubuntu.com/releases/11.10/release/ | Logs at http://irclogs.ubuntu.com/ | armhf builds are running | armhf headers at http://people.canonical.com/~ubuntu-archive/armhf/linux-libc-dev_3.2.0-2.4_armhf.deb
 * infinity points up.
<infinity> Enjoy.
 * ogra_ wishes we could quiten the perl locale warnings in perl itself one day
<infinity> Or you could not have mismatched locales.
<infinity> LANG=C chroot chroot/ su -
<ogra_> sure i just alwas forget to call chroot with LANG=C
<ogra_> i mean the message could be a one liner instead of spamming half a terminal every time
<infinity> And I just verified that with the above linux-libc-dev, build-essential installs in core.
<infinity> So, yay.
<infinity> Enjoy.
<ogra_> yeah, build-essential seems to install fine
<infinity> Actually.
<infinity> If you want to be super effin' helpful, grab the linux source package and make it stop failing on armhf. :P
<infinity> Upload with extreme prejudice, and then push a patch to apw.
<infinity> Sick of linux-libc-dev not being in the archive.
 * apw can hear you
<infinity> apw: Can you hear the grump from across the ocean? ;)
<ogra_> why the heck is everyone working on a sat.
<infinity> ogra_: It's still Friday for me.
<infinity> And will be until I sleep..
<ogra_> and why is linux not on the ftbfs list if it fails
<infinity> Cause there've been a few new uploads since.
<infinity> And it's in needs-build.
<ogra_> ah
<infinity> (But those uploads will all fail too)
<ogra_> due to the headers ? or due to the broked buildd ?
<infinity> Neither...
<infinity> Due to the arm build of the kernel not being fixed yet.
<infinity> All the recent linux uploads have been for other arch stuff.
<infinity> s/arm/armhf/
<ogra_> oh, i thought we had that bit before alpha
<infinity> armel works, but who cares about that?  Yesterday's news.
<ogra_> yeah
<ogra_> old arch ...
<ogra_> obsolete crap :P
<apw> infinity, ahh balls more arm fookage, i hate arm
<infinity> apw: It hates you too, honey.
<apw> you got somewhere you can test build a fix, i am tired of waiting for for uploads to fail
<infinity> Sure.
<doko> apw, scheat.canonical.com
<infinity> doko: There's no armhf chroot on scheat, unless lamont just fixed that?
<doko> ahh, I assume he's waiting on linux-libc-dev ;p
<infinity> Yeah, cause he wants to debootstrap it and use his script.
<infinity> apw: Fresh chroot all set up here to test.
<doko> apw, pretty please build linux-libc-dev from separate source
<apw> doko, i don't understand you have the thing buildable anyhow
<apw> maintaining that for 100s of uploads a cycle is pure madness for the 1 time every 5 cycles we need it
<apw> infinity, http://people.canonical.com/~apw/armhf/0001-UBUNTU-armhf-add-d-i-configuration.patch
<infinity> Indeed.
<apw> not that this isn't madenning
<apw> arm being so very differnet from our core arches is hard on the head
<doko> apw: no, you wouldn't need to upload it hundreds of times
<apw> its version locked to the version of the kernel right now, as it comes from the kernel source
<infinity> doko: I'm with apw, honestly.  DEB_STAGE= fixes the bootstrap issue.  After that, we need things to build ANYWAY.
<infinity> So, saying "having linux-libc-dev come from another source package means the kernel can FTBFS forever" is a bit pointless.
<doko> ok, I'll re-merge gcj and gnat into gcc
<apw> right, i thought that fixed you _if_ i could get the krenl to build, sigh
<apw> infinity, how long will your test take ?  i will prepare a source upload, and can push it later
<apw> (based on that outcome)
<infinity> apw: I dunno.  About 4 hours.  But I might be asleep when it finishes. ;)
<apw> well ... yell if and when you find out, and i can get it uploaded
<infinity> apw: Still better than wasting buildd time.
<infinity> Oh, it's already wasting buildd time. :P
<infinity> Well, better than wasting more!
<apw> infinity, heh yeah
<apw> infinity, i wonder thinking about bootstrap, i wonder what would happen if we had just uploaded the main source package but with DEB_STAGE=stage1 set, just once
<apw> that would have just bumped the useless packages, and made libc, and then uploaded it again without
<apw> then you'd have an old libc-dev and nothing else, and i'd still be ok the whole time right ?
<infinity> apw: That would work fine, yeah.
<infinity> apw: And if this test build fails, we might want to do that. :P
<apw> yeah, i'll think about that while you test :)
<infinity> Anyhow, test build is going.
<infinity> ~4 hours to build, ~â hours to nap.
<infinity> Ish.
<doko> infinity, why was the eglibc rebuild needed?
<infinity> doko: nscd depended on libsfgcc1.
<doko> bah
<infinity> Some 500ish binary packages did. :P
<infinity> Everything's reuploaded and building.
<infinity> All better "soon".
<ogra_> dont exaggerate, i only had ~300 mails on -changes when i got up :P
<infinity> ogra_: ~300 source packages, ~500 binary.
<ogra_> heh, k :)
<ogra_> (sorry i'm in fighting mode trying to help quietening a troll on ubuntu-users :P )
<infinity> Right.  Nap time.
<infinity> ogra_: If doko puts armhf buildds on manual, smack his knuckles with a ruler and remind him that building something (even if it's the "wrong" thing) is better than being idle and building nothing. :P
 * ogra_ looks for that 350km long ruler ... :P
<doko> infinity, well, 15min isn't worth this
 * utlemming is back.
<Xase> So I have a kernel booting on the nook color but it's failing to go further than halting at udev
<lilstevie> Xase: standard kernel issue with android devices, enable kernel maintained devtmpfs
<lilstevie> standard kernel config issue*
<dragonkeeper> hey anyone active ?
#ubuntu-arm 2011-12-04
<Xase> lilstevie: devtmpfs is set
<lilstevie> Xase: can you pastie your .config
<Xase> lilstevie: http://pastie.org/2963119
<lilstevie> Xase: change
<lilstevie> CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" to
<lilstevie> CONFIG_UEVENT_HELPER_PATH=""
<Xase> alright lemme try.
<Xase> even though it says not to,can I just nano that?
<Xase> or should I use menuconfig
<lilstevie> menuconfig should be easier
<lilstevie> it is in the same menu as the devtmpfs stuff
<lilstevie> also is CONFIG_CMDLINE="root=/dev/mmcblk1p2 rw noinitrd videoout=omap24xxvout omap_vout_mod.video1_numbuffers=6 omap_vout_mod.vid1_static_vrfb_alloc=y omap_vout_mod.video2_numbuffers=6 omap_vout_mod.vid2_static_vrfb_alloc=y omapfb.vram=0:8M no_console_suspend"
<lilstevie>  your cmdline?
<Xase> I think, I didn't config most of this, I'm just learning/troubleshooting.
<lilstevie> cause if so, I would remove noinitrd and actually use an initrd
<Xase> Baaah
<Xase> I'm not good at kernel configurations... now it's asking me to answer a whole bunch of stuff during make
<lilstevie> what?
<Xase> Like a walk through config.
<lilstevie> didn't work?
<Xase> Well it's like it's not reading my config file now.
<lilstevie> did you remember to ARCH=arm at the end of your make
<Xase> make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- -j4 uImage
<Xase> That's what I'm using now, and what I used before :/
<lilstevie> hm
<Xase> Configure standard kernel features (for small systems) (EMBEDDED) [Y/n/?] y
<Xase> Is it because I remoed /sbin/hotplug ?
<lilstevie> is that all it asked
<lilstevie> and shouldn't have really
<Xase> No
<Xase> It asks more if I keep answering
<lilstevie> sounds like the config got screwed
<Xase> Oh ok.
<Xase> Imported from original git now.
<Xase> Changing line
<Xase> Building, and it's not asking dumb questions now.
<Xase> Well not dumb questions, but it's not asking smart questions of a dumb guy ;)
<lilstevie> heh
<Xase> running makemenuconfig on it was breaking it :D
<Xase> 667
<Xase> Yeah, same result... Syslog fails first, and then udev repeatedly @ lilstevie
<Xase> ude.service: main process exited code=exited, status=213
<Xase> udev*
<lilstevie> oh odd
<lilstevie> that isn't the same issue I thought you were having
<Xase> Yeah udev just starts and dies repeatedly.
<Xase> You recommended setting Y to devtmpfs which was already set.
<Xase> udev.service start request repeated too quickly refusing to start
<lilstevie> have you got an initrd
<Xase> I am unsure to be honest... I'm ew and was receiving help from some other folks earlier. In my boot partitio I have uImage uRamdisk u-boot.bin and MLO
<Xase> new*
<lilstevie> what about boot.scr
<Xase> No.
<lilstevie> hm ok
<Xase> Should I make one?
<Xase> I have no clue how to do that, but I'm sure I could wing it?
<Xase> lilstevie: could it be my uRamdisk's fault?
<lilstevie> no idea tbh
<lilstevie> where is the source for uboot
<Xase> the source for u-boot was used from this source http://images.barnesandnoble.com/PResources/download/Nook/source-code/nookcolor_1.3.tgz lilstevie
<Xase> Sorry my internet goes wonky every morning between 2 and 3.
<Xase> got disconnected from my shell
<lilstevie> ok
<lilstevie> I will have a look when I get some time, see how it works et al.
<lilstevie> maybe figure out whether you need a .scr or something else done
#ubuntu-arm 2012-11-26
<dholbach> good morning
<fmoreau> hi. On the N7 using my rootfs (based on debian), I can't use the inversion Axis for the touchscreen:
<fmoreau> # xinput set-prop 6 "Evdev Axis Inversion" 1 1
<fmoreau> # xinput list-props 6 | grep Inversion
<fmoreau>         Evdev Axis Inversion (245):     0, 0
<fmoreau> does anybody have an idea ?
<fmoreau> thanks
<kulve> Ubuntu is using almost same version of the xorg evdev driver and the xorg conf for that manages to invert the axis properly..
<fmoreau> kulve: right, but the thing is that setting the option manually with xinput has no effect, not sure if this is handled by X itself or by evdev.
<kulve> fmoreau: no idea about setting it with xinput..
<ogra-cb> yay, bug 1079729 is fixed
<ubot2> Launchpad bug 1079729 in ubuntu-nexus7 "Ubuntu uninstallable on 32GB 3G Nexus 7" [High,Confirmed] https://launchpad.net/bugs/1079729
<Tasssadar> nice
<fmoreau>  does anybody if it's possible for the N7 to be accessed as a usb mass storage device ?
<hrw> fmoreau: load g_storage kernel module with proper arguments? (under ubuntu)
<xnox> fmoreau: with android installed it can be accessed over MPT protocol, not as a usb mass storage.
<xnox> fmoreau: with ubuntu installed, I don't think so.
<xnox> nfs, ssh, samba are all available with ubuntu
<fmoreau> yes I mean with ubuntu installed
<fmoreau> xnox: the point to use USB is that it's used when not network is available
<hrw> fmoreau: but you know that this would be exclusive access?
<fmoreau> hrw: can't find this module. Only g_android is
<xnox> hrw: oh, what's this g_storage you are talking about?
<hrw> xnox: usb gadget mass storage
<xnox> ack.
<fmoreau> hrw: what do you mean ?
<suihkulokki> use g_ether to make the usb a network cable
<fmoreau> only g_android is available
<suihkulokki> or even better, get a access point and forget about wires
<hrw> fmoreau: which partition you want to share over usb?
<fmoreau> hrw: /etc but / would be better
<hrw> xnox: CONFIG_USB_FILE_STORAGE CONFIG_USB_MASS_STORAGE
<hrw> fmoreau: you can not share dirs
<xnox> thanks.
<suihkulokki> fmoreau: you can't share a partition mounted already using usb mass storage
<hrw> fmoreau: and once you share parition your system loses access to it
<fmoreau> ah, I wan's aware about that.
<hrw> fmoreau: imagine that you have mmcblk0p3 as / and p5 as /home one. You can umount /home and give it as usb mass storage
<hrw> fmoreau: then umount usb storage, remove module, mount /home
<fmoreau> didn't know that the device needs to umount the shared partition
<hrw> fmoreau: can you mount /dev/mmcblk0p5 twice?
<hrw> without bind mount
<fmoreau> hrw: sure
<hrw> ok, other question. imagine x86 box. and /dev/sda5 is /storage. at same time you run other linux in VM and give it /dev/sda5 - will not work good ;D
<hrw> anyway you got it
<fmoreau> hrw: hrw then I guess I could use g_serial module instead (goal: trying to access to the N7 without network connection) ?
<fmoreau> from /proc/config.gz
<fmoreau> # CONFIG_USB_G_SERIAL is not set
<fmoreau> arcg
<fmoreau> argh
<ogra-cb> you will need to create an upstart job for it
<fmoreau> ogra-cb: what do you mean ?
<ogra-cb> else there wont be a tty on the created serial port
<ogra-cb> see the serial howto on the ubuntu wiki
<fmoreau> ok but the kernel lack of the module
<fmoreau> ogra-cb: the think is that the tty dev node should be created by udev I think
<ogra-cb> well, theer were plans to enable g_composite
<ogra-cb> but i dont think we did that yet
<ogra-cb> fmoreau, no, it shouldnt
<fmoreau> I'm not sure why upstart should be needed
<fmoreau> ogra-cb: that would be usefull I think, specially when the network is not available
<ogra-cb> upstart handles the gettys, so indeed you need it if you want to log in
<fmoreau> ah ok
<fmoreau> so... need to rebuild the kernel to enable this module
<ogra-cb> yes
<fmoreau> ogra-cb: should I follow the steps described here ? https://wiki.ubuntu.com/Nexus7/Kernel?action=show&redirect=Nexus7%2FKernelBuild#Build_zImage_only
<ogra-cb> victorp, if you like you can give the raring images a first shot ;)
<lilstevie> g_android does include several functions
<lilstevie> such as RNDIS though
<ogra-cb> still very buggy all over but you can get through (until the nux bug kicks in indeed)
<victorp> ogra-cb, !! :)
<ogra-cb> there are various new bugs too :)
<victorp> ogra-cb,  is the nux bug still haunting us?
<ogra-cb> yes
<fmoreau> lilstevie: where can I get the details about g_android ?
<lilstevie> fmoreau, have a look in init.grouper.usb.rc
<lilstevie> in the android boot.img
<fmoreau> lilstevie: ok, thanks
<ogra-cb> we'll very likely drop g_android when switching to g_composite
<ogra-cb> so dont rely on it with your code
<fmoreau> ogra-cb:
<fmoreau> $ LC_ALL=C git clone git://kernel.ubuntu.com/hwe/ubuntu-nexus7.git
<fmoreau> kernel.ubuntu.com[0: 91.189.94.216]: errno=Connection refused
<ogra-cb> as in #ubuntu-kernel
<ogra-cb> *ask
<fmoreau> ok
<ogra-cb> you can just use apt-get source btw
<ogra-cb> victorp, for manual installation: https://bugs.launchpad.net/ubuntu-nexus7/+bug/1079729/comments/37
<ubot2> Launchpad bug 1079729 in ubuntu-nexus7 "Ubuntu uninstallable on 32GB 3G Nexus 7" [High,Confirmed]
<victorp> ogra-cb, thanks - I need to work with the team about this unity bug
<ogra-cb> yeah, nux and the touchscreen issue are the most pressing ones still
<ogra-cb> (and a few new ones with the new way of installing, but i'll take care of these)
<wookey_> how do I find out if a package is in main or universe? Seems like a dumb question, but http://packages.ubuntu.com/quantal/debconf doesn;t obvsiouly say
<highvoltage> wookey_: apt-cache policy packagename usually does it for me
<wookey_> so it does. Doh
<BrokenThumb> Did anyone try to install Ubuntu on the Windows RT tablet yet? (Just a random thought that popped up in my head)
<highvoltage> Maybe if someone would actually buy them. I hear that they've been doing pretty dismally.
<prpplague> BrokenThumb: most window RT tablets use HS parts with extra security to prevent that
<prpplague> BrokenThumb: doable, but not exactly something done in one afternoon
<ogra-cb> send me one, i can try :P
<ogra-cb> unlikely to be easy or so
<BrokenThumb> prpplague: it's been out for a few weeks already? ;-)
<ogra-cb> well, "out" seems to be relative
<ogra-cb> as highvoltage mentioned ... might be "out" but still all in boxes
 * highvoltage might buy one when they go hp-touchpad and cost <$100
<ogra-cb> ++
<BrokenThumb> Oh, that'll be nice! =D
<highvoltage> heh, we're like vultures :)
<sfeole> *caw* *caw*
<xnox> wookey_: you can look at http://pad.lv/u/$source_package at the lines "published in raring release (main)"
<fmoreau> ogra_: Kernel 3.1.10+ on a 4-processor armv7l / ttyGS0
<fmoreau> localhost login:
<fmoreau> :)
<fmoreau> can log through USB now :)
<fmoreau> ogra_: would be wonderfull if g_serial is built for the next kernel image
<sfeole> Why do we see 'Error reading Mac Address from EEPROM' ?
<sfeole> when booting up the Nexus7
#ubuntu-arm 2012-11-27
<Awk9000> Hey guys, anyone installed the compat-wireless drivers on ubuntu for Nexus7 ?
<Awk9000> I've got source and headers installed
<Awk9000> i see that in the kernel config file MAC80211 and CFG80211 are set to Y
<Awk9000> do i just have to change the config file to M for modules and then recompile the kernel?
<Awk9000> and then I can just compile the compat-wireless drivers from source riiiiiiiiiiiiiight?
<Awk9000> meep?
<Awk9000> anybody....
<Awk9000> ...up?
<dholbach> good morning
<dholbach> ogra: good morning - how is the raring image looking? :)
<janimo> dholbach,  I have just installed the raring image. It needed an external keyboard here to get throught the installer
<janimo> artifacts in X, but I use it via ssh now do do non-X stuff so it's fine for me
<janimo> but the nux/unity bugfix is not yet in the image
<dholbach> really? the nux/unity thing is waiting for ages now :-/
<ogra_> dholbach, well, waiting for a nux patch
<ogra_> oh, jani said that already :)
<dholbach> <sil2100> dholbach: it's still being tested, this branch
<dholbach>  dholbach: currently it diverged from trunk anyway, so I think Jay needs to re-merge it with lp:nux
<ogra_> onboard is usable in the installer
<dholbach> <sil2100> dholbach: since anyway it cannot be approved, as there are text conflicts ;)
<ogra_> you just need to switch it on and switch off orca
<dholbach> <sil2100> dholbach: I have no nexus7, but I was able to test-build it on my pandaboard and send the whole re-built unity stack it to people responsible
<dholbach>  dholbach: so I think we might have it reviewed soon
<ogra_> (planning to research today why it comes up that way)
<ogra_> generally the images are fine though, apart from the unity/nux breakage
<ogra_> the "black bar instead of panel shadow" bug is also back
<dholbach> ogra_, but I see that in regular quantal too sometimes
<ogra_> well, it was supposed to be fixed with the PPA packages
<ogra_> (for quantal that is)
<ogra_> you didnt upgrade your device with -security or -updates, did you ?
<dholbach> ogra_, sorry I meant on, my regular laptop installation
<ogra_> oh
<ogra_> that surely shouldnt happen
<ogra_> xnox, can you add the PPA URL to bug 1082364 ?
<ubot2> Launchpad bug 1082364 in ubuntu-nexus7 "android debugger bridge cant be install on ubuntu on nexus 7" [Undecided,Triaged] https://launchpad.net/bugs/1082364
 * ogra_ forgot which PPA that was in
<xnox> ogra_: why is the PPA relevant to that bug?
<ogra_> xnox, well, because i doubt anyone wants to SRU the package :)
<xnox> ogra_: I only uploaded backported android-fs-tools into the virtualised PPA which has the installer which does not build for armhf. So you won't get adb on quantal through that.
<ogra_> oh, ok
<xnox> ogra_: or are you after mk_ext4fs for the automated cdimage? then you are free to pull source/binaries for lucid from the installer ppa.
<ogra_> no, i'm after adb for that bug :)
<xnox> ogra_: I could backport adb to the ppa, but I'd rather people switch to raring to get that =)))))
<ogra_> if the user has an opportunity to get it for his release i can close it
<ogra_> oh, indeed
<xnox> currently there is no "easy" opportunity to get that package on quantal.
<ogra_> xnox, https://launchpad.net/~ogra/+archive/ppa/+packages
<ogra_> ;)
<xnox> ogra_: phhhh..... I wonder who you bribe to get arm builders =)
<ogra_> i use the canonical-arm-dev PPA to build them
<ogra_> and then copy over binaries and source
<xnox> cheat
<ogra_> want access ?
<xnox> not really needed so far =)
<hrw> xnox: which package?
<xnox> hrw: the android-tools, since the one in raring builds all of them for armhf as well, while in previous releases it was only built for x86.
<xnox> hrw: bug ogra now built the backport in a ppa.
<xnox> s/bug/but/
<xnox> ^^^^
<hrw> xnox: SRU it
<xnox> hrw: in my opinion this change does not qualify for an SRU, but rather a backport. As it introduces new binary packges post-release. One could say it's "hardware enablement SRU" but it is pushing it, since it's hardly secure boot.
<xnox> hrw: I'd rather encourage people to run raring and focus on raring development.
<xnox> hrw: feel free to file SRU request if you want it in quantal/precise =) I just don't have time to work on that.
<hrw> xnox: I use only raring for development and when someone says "I am running latest ubuntu" meaning 'last release' I laugh ;D
<xnox> ;-)
<xnox> hrw: but then I have to write lucid compatible code to be deployed in the DC *sigh* .....
<hrw> augh
<hrw> I do have 2 precise boxes - my server and router
 * xnox bets $0.02 they were running precise before the precise release date.
<hrw> server was natty->overic->precise in 3 days
<hrw> build precise iirc before release
<brendand> xnox, a whole 2c! i want in
<xnox> brendand: well when I bet $0.07 you know I'm bluffing. It's a fine art betting multiples of small blind bets.
<ogra_> ah, great
<ogra_> i found the issue why orca shows up in ubiquity-dm instead of onboard
<xnox> ogra_: share the news =)
<xnox> bootargs?
<ogra_> yeah, sadly
<ogra_> (means i need to update them after install)
<xnox> ogra_: do you need a new accessibility setting? or like a way to detect a missing keyboard?
<ogra_> i think we have a bug open for the latter
<ogra_> not related to ubiquity though
<xnox> ack.
<ogra_> no, i dont need a new function, i think the way it works is fine
<ogra_> just need to adapt to it in my code, we need to update the cmdline anyway for UUID stuff
<brendand> ogra-cb, what's the difference between pkexec and gksu
<ogra_> pkexec is part of policykit and uses the policykit ACLs for access
<ogra_> gksu is just a sudo UI
<brendand> ogra_ - i'm not au fait with policykit
<ogra_> well, its the default authentication technique we use for desktop apps
<brendand> ogra_ - it looks like we'd lose the ability to customise the message shown to the user - unless that was added to pkexec
<ogra_> since a few releases already
<ogra_> it uses consolekit to determine your permissions
<ogra_> gksu isnt vanishing from the archive in case you ant to use it in your app (to be able to set the shown message)
<ogra_> but it will be removed from the default install
<ogra_> brendand, oh, and according to the manpage you can actually set the message
<brendand> ogra_ - speaking of problems with gksu. is https://bugs.launchpad.net/ubuntu-nexus7/+bug/1078696 gone in the raring image?
<ubot2> Launchpad bug 1078696 in ubuntu-nexus7 "gksu does not accept sudo password on the Nexus7" [Low,Confirmed]
<ogra_> (a bit more complex than just using a cmdline option indeed)
<ogra_> brendand, it will be gone once gksu is gone from the image ... the bug will still be in gksu
<ogra_> unless upstream cares to fix it i guess
<brendand> ogra_ - oh i see, we have to create a config file to do it
<brendand> ogra_ - at least it's possible
<ogra_> yeah, some xml crap
<brendand> hurray, xml :/
<ogra_> heh
<ogra_> awesome !
<ogra_> my onboard fix for oem-config works just fine
<brendand> ogra_ - so even now on the quantal preinstall image if i run my app using pkexec it will accept the password?
<ogra_> to sad it didnt make the daily build that just started :(
<ogra_> yes
 * ogra_ ponders to add the slideshow back to the image ... 
<ogra_> we're size wise on the edge so i'm not sure i shoudl do that until we have found a better compression method
<ogra_> but the installer looks so ugly
<xnox> ogra_: new ubiquity uploaded which should allow to install from sd-card to the remaining space of the sd-card without partitioning it first on a panda.
<ogra-cb> yeah. i saw the commits pasing by the last days already, awesome !!!!
<xnox> ;-)
<dholbach> mfisch, achiang: I mentioned your blog posts in one of mine - if you're not on planet ubuntu we should really get you on there :)
<mfisch> dholbach: I'm on planet ubuntu
<dholbach> ah great
<dholbach> and as I mentioned earlier: some of the content could also go to ubuntu-devel@ :)
<dholbach> and then there's the hangouts :)
<achiang> dholbach: i'm not an ubuntu member. :(
<dholbach> mfisch, thanks a lot for keeping everyone updated!
<dholbach> achiang, ... yet :)
<achiang> dholbach: want to write a testimonial for me? :)
<dholbach> achiang, sure :)
<dholbach> did you set up a wiki page already?
<achiang> https://wiki.ubuntu.com/AlexChiang
<dholbach> sweet
 * achiang has been trying to become motu for like 18 months now
<ogra-cb> wow
<mfisch> you can be a member w/o being a motu
<achiang> i was told by some people that i didn't have enough contributions to be a member either
<dholbach> achiang, done
 * achiang hugs dholbach 
<dholbach> achiang, the CC updated https://wiki.ubuntu.com/Membership to also include other forms of contributions - I think you should be well-covered now
 * dholbach hugs achiang
<dholbach> ok, time for the hangout
 * lilstevie wonders if his contributions would be considered significant enough
<achiang> dholbach: what's the url?
<dholbach> ubuntuonair.com
<ogra-cb> ssweeny, fyi http://cdimage.ubuntu.com/daily-preinstalled/current/
<ssweeny> ogra-cb, awesome! when did that start happening?
<ogra-cb> early last week
<ssweeny> oh nice
<ogra-cb> we're still waiting for the nux fix ... so the desktop stuff is pretty broken
<xnox> ogra-cb: wow, it built today \0/ well done =))))
<xnox> ah.
<ogra-cb> but you can run apps and blindly tap on the UI
<ogra-cb> its enough for testing ...
<ogra-cb> (as long as its not unity itself)
<Tassadar> ogra-cb: by the way, is initrd in Raring using different compression?
<ogra-cb> nop
<ogra-cb> just ubuntu defaults everywhere
<Tassadar> that is weird, i downloaded the boot.img for raring to see what is different, but gzip says it cannot extract initrd.img
<Tassadar> gzip: initrd.cpio.gz: not in gzip format
<ogra-cb> how did you pull it out of the bootimg ?
<Tassadar> abootimg -x
<ogra-cb> hmm, that should work
<ogra-cb> oh, apparently is lzma
<ogra-cb> must be a change in the build system
<ogra-cb> the installed initrd is definitely gzip
<Tassadar> yeah, it is lzma
<Tassadar> (well, cpio.lzma)
<ogra-cb> yes
<ogra-cb> sorry for telling you wrong, i wasnt aware, seems to be a change in live-vuild
<ogra-cb> *build
<Tassadar> hmm, looks like I'm gonna have to do the same ugly thing as I did with 12.10 to multi-boot it. Well, at least I probably won't have to edit the root images
#ubuntu-arm 2012-11-28
<dholbach> good morning
<fmoreau> hello
<dholbach> can anyone reply to https://twitter.com/yuvilio/statuses/273566993171492864 please?
<infinity> dholbach: It should be roughly the same, hardware-wise, as a Chromebook, if that's helpful.
<ogra_> right
<infinity> dholbach: There's kernel work and hobbyist fun going on there, but not by us.
 * ogra_ isnt aware of any official statements about the nx10 though
<ogra_> i guess a chromebook kernel might show up in the archive before release
<ogra_> so someone who would try to get it to work should be able to
<infinity> I'm still tossing around the idea of getting an American to send me a Chromebook.
<infinity> Which would give me incentive to maintain a kernel in the archive. :P
<ogra_> (cant be to much difference between the two)
<infinity> Part of me is still holding out for Lenovo to make an ARM laptop, so I don't have to compromise on my love of Lenovo keyboards.
<infinity> But I could be waiting a long time for that...
<RaYmAn> n10 kernel is...rather different for some reason.,
<RaYmAn> they don't use DTB's
<RaYmAn> but other than that, it should be trivial.
<dholbach> thanks everyone
<ogra-cb> dholbach, oh, and a sidenote, no redistributable GLES drivers for the nexus 10, unless that exists its very unlikely for us to switch to it simply because we cant run unity
<hrw> http://marcin.juszkiewicz.com.pl/2012/11/28/lets-compare-some-cpu/ - you may find it interesting
<dholbach> ogra-cb, if the guy replies I'll let him know :)
<ogra-cb> k
<ogra-cb> that could become our general answer to that faq :)
<ogra-cb> (i hear that question once a week, but ignore it most of the time ... )
<hrw> ogra-cb: n10 has same problem as chromebook
<ogra-cb> yes
<ogra-cb> but has no chromeos to hack around the issue
<hrw> ogra-cb: if you can spare 363MB of data and 1.4GB of disk space then I have solution
<ogra-cb> on the chromebook you can at least pull the libs from chromeos
<hrw> s/data/network data/
<ogra-cb> cant do that on the nexus10
<ogra-cb> you have a 363MB download that solves the licensing ?
<hrw> chromebook recovery image can be fetched
<hrw> but user would have to do it ;(
<hrw> the real pita of exynos5 is lack of any license infromation in chromium os (or I did not yet found it)
<hrw> https://dl.google.com/dl/edgedl/chromeos/recovery/chromeos_2913.84.10_daisy_recovery_stable-channel_mp-v2.bin.zip
<hrw> fetch, unpack, use kpartx to split partitions, mount ROOT-A as ro, copy files
<hrw> 363MB zip, 1GB img
<hrw> http://commondatastorage.googleapis.com/chromeos-localmirror is also useful if you know what you are searching for.
<hrw> but no libmali there
<lardman> hrw: libmali is the userspace closed lib?
<hrw> yes
<hrw> lardman: long time - how things?
<lardman> hrw: indeed, not bad, 14month old daughter has sort have put a hold on hobby coding up till now
<lardman> but now we're getting at least some sleep, I'm looking for some hw :)
<hrw> lardman: ;)
<hrw> 14m should be able to sleep whole night I think
<lardman> hrw: If you'd like to tell her that I'd be happy ;)
<hrw> lardman: ;))
<lardman> So back on topic, are there blobs for the Mali 400?
<hrw> no idea of mali400
<hrw> you have exynos4 or allwinner a10?
<lardman> nothing yet, umming and arring about the Nexus 10
<hrw> nexus10 has mali t604
<lardman> alternatively the Nexus 7, but I'd quite like to do some on-device opencl (if an sdk is released eventually)
<lardman> yeah, was just wondering whether they are just running slow releasing the relevant files
<hrw> I would not assume that Samsung will release anything
<lardman> the opencl sdk should come from ARM I'd have thought
<lilstevie> howdy lardman
<lardman> hey lilstevie
<lardman> am heading over to your neck of the woods early next year
<lardman> well not necessarily that close, but closer than here anyway
<lilstevie> heh
<lilstevie> where abouts?
<lardman> Adelaide
<lardman> to visit family
<lilstevie> ah fair enough
<lilstevie> not close, but closer :p
<lardman> yep
<lardman> hmm, interesting that the only installer for the the latest Mali OpenGL ES SDK for Linux on ARM is a Windows MSI file... :)
<lardman> nothing interesting in there though, shame
<ogra_> xnox, did you btw research why the current  /usr/lib/ubiquity/wallpaper fails or did you only look at compiz integration yet ?
<xnox> ogra_: working at compiz bits right now. Did not troubleshoot the wallpaper fail yet.
<ogra_> xnox,  ah, finally found the bug again (and gave it a better title) bug 1081260
<ubot2> Launchpad bug 1081260 in ubiquity (Ubuntu) "/usr/lib/ubiquty/wallpaper crashes after boot of livecd" [Undecided,Confirmed] https://launchpad.net/bugs/1081260
<xnox> ogra_: well it's interesting, but the "crash" reproducer is wrong as it needs to be called with the path to background (and error message says so)
<ogra_> yeah
<xnox> ogra_: but yeah, I'm in gtk right now to fix a compiz bug ;-)
<ogra_> http://paste.ubuntu.com/1394259/
<ogra_> thats his actual error in the ubiquity-dm log
<ogra_> seems also that wallpaper.c still uses gtk2
<ogra_> bug 1048976
<ubot2> Launchpad bug 1048976 in ubuntu-wallpapers (Ubuntu) "[UIFe] Update default ubuntu wallpaper to quantal version" [Undecided,Fix released] https://launchpad.net/bugs/1048976
<ogra_> oha !
<ogra_> plymouth works if i enable debugging
<hrw> ogra-cb: which kernel argument?
<ogra_> plymouth:debug
<hrw> cool
<hrw> btw - what plymouth does other than bootsplash? cause I do not see any difference when boot chromebook without plymouth
<ogra_> well, i also have break=bottom enabled might be that there is a race i avoid through that
<ogra_> bootslpash is an in kernel hack
<hrw> ?
<ogra_> thats the only "bootsplash" i know
<hrw> ok, let me rephrase... what plymouth does at all?
<ogra_> hmm, dropping plymouth:debug still gives me a splash
<ogra_> hrw, libplymouth does all kernel-userspace interaction (like a poor mans dbus for UI stuff, i.e. passwords, fsck input etc)
<ogra_> thats why i.e. mountall requires it
<ogra_> the rest is just bling
<ogra_> hmm, so am i brave and try it without break=bottom now ...
<ogra_> at the risk of having to reinstall my nexus
<hrw> thx
 * ogra_ doesnt get why it breaks at install time so badly
<ogra_> aha !
<ogra_> so it crashes id i dont have either plymouth:debug or break=bottom set
<hrw> http://code.google.com/p/chromium-os/issues/detail?id=36717
<ogra_> ++
<hrw> will fill similar ones for bunch of others
<hrw> openmax, mfc firmware
<ogra_> openmax, yeah
<hrw> ogra_: http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/openmax-0.0.1-r5.tbz2
<hrw> ogra_: binaries only
<ogra_> do they work ?
<hrw> ogra_: no experience with openmax here
<ogra_> i only have experience with gst-omx
<ogra_> that doesnt look like it would be anyhow related to gst
<hrw> yep
<xnox> ogra_: both ubiquity panel & wallpaper are gtk3.
<ogra_> ok
<ogra_> i thought i saw a gtk2 header but seems i looked at precise code here
<ogra_> (sorry for the false alarm due to that)
<xnox> ogra_: interesting bug 296538
<ubot2> Launchpad bug 296538 in unity-2d "warty-final-ubuntu.png is actually a JPEG file" [Undecided,In progress] https://launchpad.net/bugs/296538
<xnox> ogra_: /me ponders if the wallpaper works on e.g. xubuntu.
<ogra_> a bit old though
<ogra_> that wouldnt explsin it on the nexus7 though
<ogra_> *explain
<ogra_> we use the default ubuntu-wallpapers wallpaper
<xnox> ogra_: red-herring or something got strict.
 * xnox sees no wallpaper in the amd64 VM
<ogra_> ah
<ogra_> so not arch or flavour specific
<xnox> kvm that is.
<xnox> anyway, fixed the compiz bug will do a merge proposal now =))))
<xnox> ogra_: compiz is the last fallback, so on the images you'll need to somehow unseed metacity.
<ogra_> what i still wonder is why g-s-d doesnt just default to draw the wallpaper
<ogra_> it should just use the system defaults the desktop uses later too
 * ogra_ files bug 1084063
<ubot2> Launchpad bug 1084063 in plymouth (Ubuntu) "plymouth in raring seems to have a race condition on the nexus7" [High,New] https://launchpad.net/bugs/1084063
<ogra_> i have not the slightest idea how to debug this :(
<ogra_> the kernel goes into a reboot loop so i wont be able to capture any info
<ogra_> xnox, oh ! if i can unseed metacity, i can re-seed the slideshow i guess
<ogra_> without it eating all my space
<xnox> ogra_: well merge proposal is up. As soon as it's reviewed, I'll merge and upload new ubiquity ;-)
<ogra_> xnox, approved ;)
<ogra_> xnox, i'm wondering though if we couldnt merge all these /proc/cmdline parsing into one function and set all vars we need at the top
<xnox> ogra_: cheat. what about three-pairs of eyeballs? =)
<ogra_> well, if you feel like
<ogra_> i assume you have tested that before requesting
<xnox> ogra_: also on nexus do you need to move the ubiquity because of onboard?
<ogra_> move ?
<xnox> ogra_: yes, literarly move the ubiquity window around the desktop
<ogra_> the current nexus image is fine apart from missing slideshow and wallpaper
 * xnox didn't enable that compiz plugin, nor resize.
<xnox> ack.
<xnox> ok, merge and upload I guess =)
<ogra_> onboard cares for that itself
<xnox> cool =)
<ogra_> if it detects it covers the focused input area *it* moves around
<ogra_> no need to move the windows ;)
<ogra_> its a bit jumpy in the user setup screen
<ogra_> but nothing we can avoid atm
<ogra_> unless we switch to ion3 or awesome and use a fixed two pane layout ;)
 * xnox glares at ogra for daring to mention tiling window managers
<ogra_> hey its a tablet, they are perfect for that
<ogra_> its the predecessor to BathroomWindows^WWindows Metro
 * ogra_ adds various sleeps to the initrd init to see if that helps plymouth
<ogra_> hmm, no, doesnt look like
<ogra_> YAY !
 * ogra_ updates bug 1084063
<ubot2> Launchpad bug 1084063 in plymouth (Ubuntu) "plymouth in raring seems to have a race condition on the nexus7" [High,New] https://launchpad.net/bugs/1084063
<ogra_> bug 1083723
<ubot2> Launchpad bug 1083723 in upstart (Ubuntu Raring) "'telinit u' has a cage fight with busybox init" [Medium,Triaged] https://launchpad.net/bugs/1083723
<vanhoof> ogra_: are the new dailes down in size to not have to use -S?
<ogra-cb> vanhoof, yes, they should just work now (limited to 6G indeed)
<vanhoof> ogra-cb: sweet
<ogra-cb> i havent tested todazs, but yesterdays was fine
<ogra-cb> *todays
<[mbm]> did anyone ever get anywhere with nexus7 multiboot?
<Tassadar> yeah)
<[mbm]> link?
<Tassadar> http://forum.xda-developers.com/showthread.php?t=2011403
<xnox> ogra_: can we purge https://wiki.ubuntu.com/ARM/RootfsFromScratch/QemuDebootstrap, https://wiki.ubuntu.com/ARM/RootfsFromScratch, https://wiki.ubuntu.com/ARM/RootStock from the face of earth
<xnox> ogra_: and redirect people to: $ ubuntu-core images or $ mk-sbuild --arch armhf raring
<xnox> ogra_: do we have cloud-init armhf images? those work great with quick download & launch a qemu instance.
#ubuntu-arm 2012-11-29
<Ethernin> Hey guys
<Ethernin> trying to recompile the Ubuntu-nexus7 kernel with MAC80211 and CFG80211 set to "M"
<Ethernin> getting 'undefined reference to' for like every function of CFG80211
<Ethernin> ie:  /root/ubuntu-nexus7/drivers/net/wireless/bcmdhd/wl_cfg80211.c:6016: undefined reference to `cfg80211_scan_done'
<Ethernin> any thoughts or help would be greatly appreciated
<Ethernin> thanks
<Awk9000> Hey guys, so I'm trying to recompile the kernel for ubuntu 12.10 for the Nexus7
<Awk9000> changed the kernel config file so MAC80211 and CFG80211 are set to 'm'
<Awk9000> and when I go to recompile I run into 'undefined reference to' errors for every function of CFG80211
<Awk9000> any ideas or suggestions in the right direction would be greatly appreciated
<Awk9000> thanks!
<lilstevie> Awk9000, you will also need to set BCMDHD to "m"
<Awk9000> awesome!
<Awk9000> thank you!
<Awk9000> im cross compiling, do u think that has something to do with it?
<lilstevie> no, it has everything to do with the bcmdhd driver requiring those symbols
<TheMuso> I would have thought that the kernel config system would recognise this somehow and make that change...
<TheMuso> Talk about possibly shooting yourself in the foot.
<TheMuso> But then I guess its mostly distro folks who deal with kernel configs these days anyway.
<TheMuso> Or people who know what they're about.
<infinity> Kernels config deps are indeed supposed to prevent you from building something in if its deps are built as modules, but bugs happen.
<Awk9000> OK - so can i ask a dumb question?
<Awk9000> im following this guide on https://wiki.ubuntu.com/Nexus7/Kernel
<Awk9000> and tried the cross compiling on ubuntu 12.04
<Awk9000> using debuild
<Awk9000> it creates .udeb packages
<Awk9000> so can I just install those on the Nexus7 ubuntu image directly without modding the kernel on the device itself?
<Awk9000> I've always just compiled on the device itself, like the N900 for instance
<Awk9000> so the cross compiling is kinda confusing to me...
<Awk9000> but lilstevie i will try what u said and see what happens
<Awk9000> thanks man
<Awk9000> Hey everyone...not to shake up a barrel of monkeys, but anyone know if packet injection / monitor mode works on the internal wireless card????
<Awk9000> ;-D
<Awk9000> haven't googled the exact card yet, know its a broadcom which gives me some hope knowing about the injection developments lately for broadcom chipsets....
<Awk9000> holy F#@! lilstevie YOU ARE THE F'ING MAN!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
<Awk9000> MUWHAHAHAHAHAAHAHAHAHA
<Awk9000> THE MOLECULAR AMPLIFICATION CHIP WORKS!!!!
<Awk9000> ALL HAIL LORD AND RULER KRANG OF DIMENSION X!!!!!!!
<Awk9000> oh wait...
<Awk9000> shit...
<Awk9000> may have spoke too soon.....
<Awk9000> getting warnings...
<Awk9000> come on....baby.....WORK
<infinity> Awk9000: The .udeb packages are for debian-installer, it's the .deb packages you should be interested in.  Namely linux-image-$(abi)-$(flavour)_$(version).deb
<infinity> Awk9000: And yeah, just installing that with 'dpkg -i foo.deb' should do the trick.
<Awk9000> awesome ya, im familiar with 'dkpg -i foo.deb', so .udeb is for the gui installer in ubuntu or debian in general?
<Awk9000> udeb = ubuntu deb?
<Awk9000> thanks for the response infinity!
<Awk9000> so basically I'm trying to install the compat-wireless drivers on Ubuntu 12.10 for the Nexus 7
<Awk9000> which is why I'm mucking with the kernel config to begin with
<Awk9000> anyone had any luck with that yet?
<infinity> Awk9000: udeb = micro deb, special stripped down debs for the installer.
<Awk9000> awesome thank you sir!
<Ethernin> Hey guys, i just successfully recompiled the kernel on Ubuntu for the Nexus7, but am not sure exactly how to install it properly?
<Ethernin> is it just make install?
<Zero_Chaos> Can anyone teach me how to update a kernel on nexus7? we built a new kernel but make install doesn't seem to make it actually install
<Ethernin> http://www.mattfischer.com/blog/?p=285
<dholbach> good morning
<ogra_> xnox, i would love to put all of these wikipages to death, i was actually waiting with deleting them because  there was supposed to be a live-build howto from linaro one day for making a rootfs ... as a replacement to point to (ubuntu-core isnt really an alternative at all to what the tools from the wiki do)
<ogra_> that howto still doesnt exist though
<xnox> ogra_: so arm debootstrap is still not what one wants?
<ogra_> no
<ogra_> look at rootstock, it did the complete configuration on top
<ogra_> for a plain development chroot or for running a vm ubuntu-core is great, for using it as a rootfs as non experienced linux user it isnt
<xnox> i see.
<xnox> the real bug report was that it was not easy to find $ mk-sbuild --arch armhf
<ogra_> the purpose of the tools was a completely preconfigured rootfs, completely independend from the HW
<xnox> and that rootstock has higher google ranking
<xnox> so somewhere "compiling ubuntu packages for armhf" should be documented better.
<ogra_> (admittedly rootstock is full of hacks i woul implement it completely different today ... (live-build in LXC using proper preseeding to do the config)
<ogra_> well, that documentation should be somewhere in the general "compiling stuff" wiki section i think
<ogra_> or "building packages"
<infinity> ogra_: live-build can be fed starter tarballs, the right answer is probably a quick 3-line howto that says "call live-build this way and feed it ubuntu-core.tar.gz as the starter".
<infinity> Or, rather, s/live-build/linaro-media-create/ perhaps.  My brain's a bit fried.
<infinity> Or potentially either could do what rootstock does.
<infinity> Meh.
<ogra_> right
<infinity> Anything but rootstock.  Down with rootstock.  Rawr!
<infinity> I should nap.
<ogra_> well, vanhoof keeps it alive
<infinity> I'm obviously losing it.
<infinity> I was about to type "vanhoof: stop that", but he's not in the channel.
 * xnox ponders if I should troll on /j #linaro /msg #linaro I am using rootstock and it fails to create a rootfs for me. Please help!
<ogra_> hehe
<hrw> ;D
<lilstevie> lol
<lardman> Decided on a Nexus 7 (with data) despite the quoted "1-2 week until shipping", and it looks like it should arrive today (i.e. a day later)
<lardman> that's quite impressive
<lardman> imo
<RaYmAn> or alternative, very unimpressive. Their webshop doesn't seem to have much to do with reality :P
<lilstevie> :p
<Bundzi> hi, is there a way to force a custom edid value for a pandaboard running ubuntu
<Bundzi> i have a screen problem at max resolutions it flickers and is blurry
<ogra_> i dont think there is, wait for robclark to get up :)
<Bundzi> bummer
<me500> unity still functions but with glitched graphics, how do I reset on nexus 7?
<ogra_> you cant, its a bug in the widget library unity uses
<me500> damn
<ogra_> we're waiting for a fix in 13.04 ...
<me500> so no apt-get --reinstall fix?
<ogra_> 12.10 has the fix in the preinstalled image but not in the archive (which is why you should never upgrade that image as scattered everywhere across the docs)
<me500> lol woops
<me500> only followed the install guide ;p
<ogra_> me500, https://wiki.ubuntu.com/Nexus7/FAQ#Why_are_-updates_and_-proposed_disabled.3F ;)
<ogra_> dholbach, when was the nexus FAQ switched to askubuntu ?
<ogra_> the five questions there give quite a poor impression compared to the wiki FAQ
<me500> i can reinstall with the tool though right?
<ogra_> sure
<me500> goooood
<ogra_> (you could surely try to fix it and probably even succeed, but i guess a reinstall would only eat 10% of the time ;) )
<dholbach> ogra_, no idea - cwayne should know
<ogra-cb> k, i'll ask him then
<robclark> Bundzi, there was some mechanism added to load an edid value from a firmware file specified in a bootarg..  don't remember quite off the top of my head which kernel version that landed in, but I guess you should be able to find it with a bit of google searching..
<ogra-cb> http://shop.intrinsyc.com/products/dragonboard-mobile-kit
<ogra-cb> "Its Split design offers a SO-DIMM form factor SOM [....] , Education Connector, JTAG & a 2nd Display port."
<ogra-cb> what the hell is an "Education Connector" ?
<Tassadar> wow :D
<Tassadar> gpio pins maybe..?
<Tassadar> nah, they are listed separately
<brendand> ogra-cb, http://mydragonboard.org/apq8060a/ refers to it as GPIO/Education connector - so Tassadar was right
<brendand> just bad description on the intrinsync shop
<ogra_> heh, yeah
<hrw> ogra_: planning to buy.get dragonboard?
<ogra_> hrw, heh, surely not
<hrw> ogra_: ping me in two weeks and I will tell you what is in 'education' connector
 * ogra_ imagines a brain funnel for shredded books
<hrw> I got 100% price discount
<hrw> brb
<ogra_> geez, just 100% ? make them give you 200 !
<ogra_> :)
<ogra_> xnox, hmm, intresting, the recent image has the new ubiquity but also metacity-common and libmetacity-private0a ... not metacity itself though
<xnox> lol. interesting. I will investigate madison.
<xnox> ogra_: do you have java-gnome installed?
<ogra_> nope, no java at all
<ogra_> gir1.2-javascriptcoregtk-3.0 and libjavascriptcoregtk-3.0-0 are the only matches for java in the manifest
<ogra_> hmm, i wonder why every build seems to grow in size
<ogra_> todays build is 4M bigger
<dholbach> ogra: once we have the raring image and the nux fix - will we tell people to upgrade or reflash?
<dholbach> ogra_, sorry - picked the wrong *ogra*
<ogra_> heh
<ogra_> all of they are highlighted in all my xchats, no worries :)
<ogra_> *them
<ogra_> (tsk)
<ogra_> dholbach, both should work (theoretically)
<dholbach> ogra_, what will we recommend?
<ogra_> i think we should recommend re-flashing so people get a personalized device
<dholbach> ok
<sfeole> dholbach: i updated the wiki last night with manual instructions to flash raring, you probably noticed by now.
<sfeole> :)
<dholbach> ah, so it has the nux fix already?
<sfeole> dholbach: not yet
<sfeole> dholbach: hopefully very soon
<dholbach> gotcha
<ogra_> you can pretty well play around with the raring image if you know your way around
<ogra_> i.e. testing via ssh etc
<sfeole> yea or use a usb/keyboard and ctrl-alt-T to open a terminal window
<ogra_> works in onboard as well :)
<sfeole> i might make a note on the wiki later today that the raring installer has a corrupt background and it's a known issue
<ogra_> yeah, and that the slideshow is missing
<ogra_> i dont really have the balls to put it back, we're so close to oversized
<sfeole> ogra_: want me to file launchpad bugs as well?
<ogra_> i think for the wallpaper there is a bug
<sfeole> ahh ok
 * sfeole takes another look
<ogra_> if you want to file one for the missing slideshow as a reminder, then assign it to me
<sfeole> ack will do
<sfeole> ogra_: your talking about the installer slideshow right?
<ogra_> yep
<ogra_> without it the actually process window gets very tiny ...
<ogra_> and jumpy in size
<sfeole> i think it will look just fine without it, once the background is fixed
<ogra-cb> xnox, compiz/ubiquity works fine on the nexus
<ogra-cb> i also get a proper black wallpaper instead of the corrupted crap i had before
<ogra-cb> that the windows are immovable feels very weird though
<xnox> =)
<ogra-cb> (and i had plymouth instead of staring at a "localhost.localdomain login:" prompt )
<ogra-cb> lots better
 * Laney looks forward to trying out the nexus7 images
<Laney> i'll wait for nux though ;-)
<ogra-cb> grmbl
<ogra-cb> why does the powerbutton still trigger a dialog
<tassadar_> ha, nice, support for kexec-hardboot got into official N7 Ubuntu kernel :)
#ubuntu-arm 2012-11-30
<Zero_Chaos> so anyone here using a nexus7 and built a kernel natively? I'm wondering why initrd.img is always so huge that it can't fit
<TheMuso> /c/c
<TheMuso> Probably because you have extra stuff on your system that makes the initrd bigger when its generated.
<Zero_Chaos> TheMuso: not really familiar with how ubuntu knows what to put in the initrd so no clue how to trim it. any ideas?
<TheMuso> Zero_Chaos: Without knowing whats installed on your system, its hard to give specific advice. But you could check to see what packages are associated with the files in /usr/share/initramfs-tools/hooks. Those scripts are responsible for helping create the initrd, and adding extra bits to the initrd image. Someone else may have a better idea though.
<Zero_Chaos> TheMuso: that sir is exactly what I needed to know. thanks
<Zero_Chaos> TheMuso: stupid device is charging right now (killed the wifi so can't ssh to it and charge at once) but soon, soon I'll play with that
<Zero_Chaos> TheMuso: note to other, when recompiling the kernel it seems bcmdhd doesn't work so hot anymore. seems to be missing it's nvram file
<lilstevie> Zero_Chaos, you probably aren't using the correct config
<lilstevie> extract it from /proc/config.gz of the ubuntu kernel to compare
<Zero_Chaos> lilstevie: I did. I change it to a module from builtin.
<Zero_Chaos> lilstevie: ALWAYS start from a working kconfig ;-)
<lilstevie> forgive me I don't mean to accuse that was just some advice given :) point is the nvram file exists in lib/firmware so a new compile of the kernel will not change that
<Zero_Chaos> lilstevie: yeah but it will cause failures if, for instance, the loader can't find the firmware when it's not builtin... which it was, and now isn't.
<Zero_Chaos> lilstevie: and the caps was a stressing of a point not trying to show anger.
<lilstevie> Zero_Chaos, the firmware isn't built in
<Zero_Chaos> lilstevie: it was definately for the 4329, I can't double check the bcmdhd right now due to the aforementioned power failure
<lilstevie> uh no, I can assure you the firmware does not get built in, and I do not know any bcm4329 devices that do either
<Zero_Chaos> lilstevie: since I lack the ability to jump onto the device right now (it's not even in the same state as me) I'll smile and nod. but when my hands get home and plug it back into the network for me we can have it out ;-)
<lilstevie> Zero_Chaos, I maintain a kernel for the tf201, which is bcm4329
<lilstevie> it is modular
<lilstevie> but even if it isn't, if the firmware is not at the specified location it will fail to load
<Zero_Chaos> lilstevie: you we are working on completely different devices then? and the one I'm working on claims to have 6100 patches added to it... couldn't be any changes in there.
<lilstevie> Zero_Chaos, also, if the firmware was built into the kernel they would not need to distribute it in linux-firmware-nexus7
<Zero_Chaos> lilstevie: original kernel worked with wifi, I "zcat /proc/config.gz > /usr/src/linux/.config && make && make modules_install && make install" then some dance to flash the kernel on the dev and the wifi no worky. only change before make was making wifi module
<lilstevie> Zero_Chaos, bcmdhd can be problematic when built as a module
<lilstevie> just fyi
<Zero_Chaos> lilstevie: really... because it's working just so well over here.
<Zero_Chaos> lilstevie: any ideas how to make it work? dmesg was crying about missing nvram something or another (should be able to get real text in ~20 min)
<lilstevie> can does not mean always
<Zero_Chaos> lilstevie: it was sarcasm, it doesn't work at all
<lilstevie> :p
<lilstevie> bcmdhd doesn't work at all under ubuntu on the tf201
<lilstevie> but works fine with android
<Zero_Chaos> lilstevie: that's like saying bcmdhd doesn't work in gnome but works in kde. the only thing that affects the kernel wifi modules is the kernel.
<lilstevie> actually not the case
<lilstevie> there are those userspace libraries that differ between android and ubuntu
<Zero_Chaos> lilstevie: and userspace libs affect the kernel wifi module how exactly?
<lilstevie> I give up
<lilstevie> seriously
<Zero_Chaos> lilstevie: fine, leave me bored waiting for a device to hack on. :-)
<Zero_Chaos> lilstevie: you still here
<lilstevie> yes
<Zero_Chaos> <*>   Broadcom 4329/30 wireless cards support
<Zero_Chaos> (/lib/firmware/fw_bcmdhd.bin) Firmware path
<Zero_Chaos> (/lib/firmware/nvram.txt) NVRAM path
<Zero_Chaos> it builds the firmware in
<Zero_Chaos> happy birthday
<Zero_Chaos> sorry it took so long
<lilstevie> nope it doesn't
<Zero_Chaos> lol
<lilstevie> that is the reference paths to where it will find it in the filesystem when you boot
<lilstevie> I dare you to remove those firmware files after the kernel is built
<Zero_Chaos> dare huh?
<lilstevie> :p
<lilstevie> because I know it will be looking for those files in the filesystem
<lilstevie> meaning boot after deleting them, you will have no wifi
<Zero_Chaos> interesting challenge. I've never in my life seen a driver that allows you to set a random name for the firmware file.... but perhaps this is one like that
<lilstevie> you are talking about a driver that is made for android, there is nothing sane about it
<Zero_Chaos> I don't see a call to udev to pickup the firmware but I may just be missing it
<Zero_Chaos> drivers are made for linux
<Zero_Chaos> android is just a cute little gui
<lilstevie> android is a userspace
<Zero_Chaos> well yes and no, there is still a lot of linux like userspace
<lilstevie> android doesn't even use libc, they use their own custom implementation
<Zero_Chaos> yeah so does everything embedded, that doesn't mean it's not linux
<lilstevie> but still, the driver is for android
<Zero_Chaos> it's a userspace driver?
<Zero_Chaos> why am I recompiling my kernel then?
<lilstevie> as in, androids stupid custom libs, and filesystem layout
<lilstevie> up until recently bcmdhd class drivers didn't work with network manager without patches
<Zero_Chaos> yeah but nm sucks ;-)
<lilstevie> no, in this case it is the driver that sucks
<lilstevie> to android it is just an ethernet card interface
<Zero_Chaos> well the driver isn't mac80211/nl80211/etc so it's no surprise
<Zero_Chaos> yeah, that's why these things are so loved
<Ethernin> freakin android is a mess
<Zero_Chaos> android sucks like hell
<Ethernin> why the hell can't they just make it full blown linux already/?!?!
<Zero_Chaos> let's make a pwnphone android rom
<Ethernin> and what the hell ever happened to ubuntu mobile anyway??
<Ethernin> lol
<Ethernin> have u seen um
<Ethernin> fuck
<Ethernin> what is it called
<Ethernin> dsploit
<Ethernin> that's it
<Ethernin> pentesting android rom
<Zero_Chaos> Ethernin: hey
<Ethernin> course it does no wireless packet injection whatsoever
<Zero_Chaos> Ethernin: dude, check what channel you are in
<Ethernin> seriously though, does anyone here know what happened to ubuntu mobile?  are they working on releasing a ubuntu for phones?
<lilstevie> fwiw Zero_Chaos I thought you may want a little more real evidence of my claims
<lilstevie> module_param_string(firmware_path, firmware_path, MOD_PARAM_PATHLEN, 0660);
<lilstevie> module_param_string(nvram_path, nvram_path, MOD_PARAM_PATHLEN, 0);
<lilstevie>  /* load firmware and/or nvram values from the filesystem */
<lilstevie> the last was meant to be first
<Zero_Chaos> lilstevie: I guess it makes some sense though. considering it has to understand that messed up hierarchy in android and the slightly more sane standard linux one.
<lilstevie> yes
<lilstevie> that is the point
<lilstevie> although the config you showed seems to have more than what it is meant to defined
<lilstevie> bcmdhd is meant to only be the path to the folder
<Zero_Chaos> lilstevie: it was what I pulled from /proc/config.gz
<lilstevie> older versions (bcm4329 bcm4330) were full filename
<lilstevie> I didn't say it wasn't
<lilstevie> it will work all the same
<Zero_Chaos> lilstevie: this is from a 3.1.10 kernel, not that old but not new
<lilstevie> you missed what I said bcmdhd is new
<lilstevie> prior to that it was bcm4329 or bcm4330
<Zero_Chaos> lilstevie: oic, interesting
<lilstevie> and I am aware about the kernel, this is the newest nvidia is working with at present
<lilstevie> which is silly
<lilstevie> but meh
<Zero_Chaos> yeah, now I just need to hack it up to work with compat-drivers and then no care. :-)
<Zero_Chaos> but that seems a lot harder than expected
<Ethernin> lilstevie, have u tried recompiling the android kernel with usb wifi options?  / MAC80211 / CFG80211?
<Zero_Chaos> Ethernin: we had the alfa working fine yesterday
<Ethernin> just curious, i know source is kinda hard to come by as far as i know
<Zero_Chaos> Ethernin: it is pretty much the same kernel
<Ethernin> ya, the kernel on the android 4.whatever i was working on was something weird like 3.0.8
<Ethernin> but ya
<Zero_Chaos> Ethernin: considering this kernel is reasonable close to android's kernel, I'm pretty confident if I can make compat-wireless work for it I can do it on android
<lilstevie> Ethernin, for the tf201 I do, I compile for most usb wireless devices
<Ethernin> dank
<Ethernin> well heck, after this nexus 7 ill have to get back to work turning the SG3 into the next pwnphone
<Ethernin> at least until jolla comes out with the next N900
<Ethernin> the motorolla atrix is not bad either
<Ethernin> HTC one x+ is fast but no mircosd, and you can't take out the battery!
<Zero_Chaos> Ethernin: moto droid4?
<Zero_Chaos> :-)
<Zero_Chaos> Ethernin: has a keyboard and good battery life. but it's a bit slow
<Ethernin> !?!?
<Ethernin> dual core?
<Ethernin> ya but isn't it verizon only?
<Zero_Chaos> I think not, but not really sure
<Ethernin> i looked into droids for a while and pretty sure they're verizon only which is a major bummer
<dholbach> good morning
<davecheney> raring-29-nov-nexus-7 image is busted :(
<davecheney> heroic video corruption once it struggles to the desktop
<ogra_> davecheney, yes, known
<ogra_> davecheney, thats the reason we are not making much noise about these images yet ;)
<ogra_> davecheney, the more important fact is that you got through the installer and into the desktop, thanks for the feedback !
<davecheney> ogra_: well, glad I could help
<ogra_> i'll add the images to the channel topic once they are good enough for usage
<ogra_> (and there will be blog posts etc)
<davecheney> cool
<davecheney> ogra_: turns out that I have two nexus 7's
<ogra_> bug 1065638 btw
<ubot2> Launchpad bug 1065638 in ubuntu-nexus7 "Unity panels don't display visuals" [Critical,In progress] https://launchpad.net/bugs/1065638
<davecheney> so expect more bug reports
<ogra_> yay, great !
<davecheney> ogra_: u canonical ?
<ogra_> yep
<davecheney> me too
<davecheney> oh fuck, i just quit onboard
<lilstevie> ogra_, turns out that I have no problems with plymouth because I had FRAMEBUFFER=y in my initramfs-tools config
<davecheney> trying to make it always on
<ogra_> enable the "floating button" option
<ogra_> always on will get in your way
<lilstevie> ogra_, so yes, it does work with quantal as well
<davecheney> yeah, i was trying, but I hit quit, instead of prefs
<ogra_> lilstevie, yeah, my prob is that our bootimg cant be bigger than 8M and the wlan driver is compiled into the kernel ... which gives me a 4M vmlinuz
<lilstevie> ogra_, yeah ouch
<ogra_> setting FRAMEBUFFER pulls enough stuff in to make my initrd to big
<lilstevie> ogra_, yeah, understood my initrd is 8MB on its own
<ogra_> *envy*
<ogra_> but your boot will be slower :P
<lilstevie> ogra_, it is the trade off
<lilstevie> ultimately I find that it is worth it
<lilstevie> but that is my opinion
<ogra_> instead of having to hack defaults ? yeah
<ogra_> we have way to much useless stuff in our initrd
<lilstevie> it isn't only that, from time to time I do find myself using android
<lilstevie> which  is certainly much easier to manage
<lilstevie> and size
<lilstevie> for a very long time I was fighting size with the tf101
<lilstevie> at one point I increased the size of LNX purely for the extra space required
<ogra_> well, i like to stay with the device defaults where the bootloader defines the partitioning so people dont get issues rolling back to the original OS
<lilstevie> yeah well that is what has happened this time
<lilstevie> using lvm to tie partitions together means that it is just a wipe and restore with recovery away from stock
<lilstevie> -rw-r--r--    1 root     root        7.9M Nov 30 05:39 initrd.img-3.1.10-1-transformer-tegra3
<lilstevie> -rw-r--r--    1 root     root        3.5M Nov 16 10:13 vmlinuz-3.1.10-1-transformer-tegra3
<lilstevie> wouldn't be possible before
<lilstevie> :p
<lilstevie> next step though is to trim down the kexec host kernel, I'm sure a lot of the unneeded cruft that is left in the kernel which would be used under normal boot conditions will be slowing boot down
<ogra_> xnox, so how about using the compiz wallpaper plugin in ubiquity ?
<xnox> ogra_: it already suppose to do it.
<xnox> ogra_: but nothing shows up =(
<ogra_> oh, i only saw the decoration plugin on your commandline
<xnox> ogra_: there is --background as well.
 * xnox is not sure if it needs a plugin or just that command line option though
<xnox> (or whatever it is --background-img?!)
<ogra_>  wm_cmd = ['compiz', '--sm-disable', '--fast-filter', 'decor']
<ogra_> thats what i see in the merge request, did you change it ?
<ogra_> oh
 * ogra_ missed wm_cmd.extend(['--bg-image', background_image])
<ogra_> ignore me :P
<hrw>  /ignore ogra_
 * xnox likes hrw
<dholbach> I'm not sure if my last message actually made it here....
<dholbach> <dholbach> ogra_, is "update-manager -c -d" supposed to work on the nexus7? :)
<dholbach>  it presents me with the option to upgrade "your up-to-date, but there's 13.04" and if I click on "update..." it just exits
<dholbach> I could just go into /etc/apt/sources.list and dist-upgrade manually, but I thought I'd check the more obvious solution first
<ogra_> dholbach, sure, that should work
<ogra_> (update-manager)
<ogra_> suihkulokki, *all* image/rootfs builder tools should export FLASH_KERNEL_SKIP=true, then flash-kernel will DTRT
<ogra_> just make sure to export it somewhere in your live-build config
<suihkulokki> sounds greek to me :P
<infinity> No, that's markos.
<ogra_> hah
<suihkulokki> ogra_: you mean the bug is in linaro-media-create that should set FLASH_KERNEL_SKIP=true
<ogra_> suihkulokki, exactly
<ogra_> that will prevent flash-kernel from trying to flash/write to a bootloader partition
<suihkulokki> ok, I'll poke people to do that
<ogra_> thx
<infinity> How did we end up needing this hack with 3.0, when 2.x was fine in chroots?
<ogra_> 2.0 had that too
<infinity> Was it in our livecd-rootfs configs back then?
<infinity> Maybe I just don't remember. :P
 * suihkulokki unsure which one to hate more - flash-kernel or linaro-media-create
<infinity> Oh, even livecd.sh had it.
<infinity> Alright.
<infinity> It's always sucked. :P
<ogra_> right
<infinity> Althought, we don't suppress anymore, we now dpkg-divert.
<ogra_> originally added on 2011-01-26
<dholbach> ogra_, it doesn't, but I talked to mvo about it -- nux/unity should land early next week according to didrocks
<dholbach> ogra_, they're still working on some test-suite issues
<ogra_> i hope so
<dholbach> yes, me too
<ogra_> i really want to make the alpha1 date with the images
<infinity> ogra_: Ubuntu's not doing alphas anyway...
<infinity> ogra_: Welcome to raring. :)
<ogra_> infinity, i know, but that was my point in time i have set as target for having working images
<ogra_> i still like to use milestones for scheduling ;)
<infinity> Fair enough.
<infinity> I say they should work yesterday.
 * infinity waits.
<infinity> DO THEY WORK YET?!
<ogra_> they do
<ogra_> since last week
<ogra_> the desktop doesnt
<infinity> Who needs that?
<ogra_> heh
<infinity> Commandline tablets are all the rage.
<achiang> dholbach: hi, what time is the meeting today? :)
<dholbach> achiang, half an hour?
<dholbach> achiang, what's on the agenda?
<dholbach> achiang, I'll announce it on the @ubuntudev channels
<achiang> dholbach: i think we can do general q&a and also general discussion re: memory leaks
<achiang> dholbach: have you read my latest blog entry?
<dholbach> yes, I shared it through @ubuntudev too :)
<achiang> heh, ok
<achiang> kyleN_: ^^
<kyleN_> ack
<dumby88> RK2918
<dholbach> does anyone have their nexus7 on raring already? was onboard deinstalled for you during the installation too?
<dholbach> err, upgrade
<dholbach> ogra_, can you please reupload onboard into the nexus7 ppa?
<dholbach> so it picks up the new python
<dholbach> right now it's uninstallable
<dholbach> into the raring ppa pocket
<dholbach> or maybe upload it straight to the archive :)
<dholbach> ^ or anyone else in ~ubuntu-nexus7 really
<dholbach> I assume a changelog-only upload, maybe for virtkey too (have to check) will do it
<ogra_> why is there an onboard at all in the PPA ?!?
 * ogra_ doesnt knwo who uploaded that
<ogra_> i have no issues with onboard on the raring images
<dholbach> ogra_, you did
<dholbach> ah no
<dholbach> sorry
<dholbach> ssweeny
<dholbach> https://launchpad.net/~ubuntu-nexus7/+archive/ppa
<ssweeny> I uploaded it at the behest of the onboard devs
<ssweeny> dholbach, what's the issue with onboard and python? was there an update?
<dholbach> no, but it can not be installed in raring
<dholbach> because it wants python << 3.3
<dholbach> a simple rebuild should do it
<ssweeny> in raring people should be using the archive version i would think
<ogra_> why ... the version in raring should outsmart the one in the PPA
<dholbach> but maybe we should just get the new version into the archive
<ssweeny> unless upstream hasn't released yet...
<dholbach> ssweeny: the version in the ppa is higher
<ogra_> ouch
<ssweeny> ah, hm
<dholbach> 0.99~tr1071-0nexus7.1 vs 0.98.2-0ubuntu1
<ssweeny> so the version in the PPA is a snapshot of an upcoming release
<dholbach> are we in touch with upstream?
<ssweeny> i was lead to believe that the release was coming soon and that it would go straight into raring
<dholbach> nothing in the sponsoring queue
<ssweeny> the snapshot has a fix for the performance issue with the ambiance theme
<dholbach> ok, shall I mail upstream and CC you?
<ssweeny> that would be great
<dholbach> alright
<dholbach> will do
<dholbach> done
<ssweeny> great, thanks dholbach
<dholbach> anytime
<bootidsa> Anyone here from meetingology today ?
<philhug> is anyone familiar with the odroid-x2 or -u2?
<Quinto68> hi someone has pcre package for arm?
<Quinto68> i have this error
<Quinto68> error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory
<Quinto68> hi someone has pcre package for arm?
<Quinto68> error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory i have this error
<lardman|home> Is there any thought to provide dual booting ability for the Nexus 7?
 * lardman|home looks at the installer script
<lardman|home> Ah, I seem to remember someone mentioning that this is often asked.... :)
 * Tassadar throws http://forum.xda-developers.com/showthread.php?t=2011403 at lardman|home
<lardman|home> this potentially looks to be a better bet: http://forum.xda-developers.com/showthread.php?p=34853595
<lardman|home> place the Ubuntu kernel in the recovery partition, etc.
<Tassadar> and both android and ubuntu to /data at once?
<lardman|home> yeah I'm wondering quite what the deal is there
<lardman|home> then again the link you pasted my have changed since I looked at it yesterday
<Tassadar> I am not saying that it does not work, just that it is _kinda_ dirty
<lardman|home> would be good to repartition and then install Ubuntu to its own one (as I have a 32GB device)
<Tassadar> I don't think that's really an option
<lardman|home> Tassadar: I wasn't so keen on the multiboot method of copying boot partition everytime
<[mbm]> haven't looked at the existing solutions, but it should be pretty easy to create a /data/ubuntu; android will ignore that and the ubuntu initrd would need to be altered slightly to use it as a root
<[mbm]> I don't think repartitioning is an option given that I don't see an actual partition table
<lardman|home> there are the wonderful pit files iirc
<lardman|home> though yeah, sounds quite messy
<Tassadar> lardman|home: me neither, but kexec-hardboot compatibility is already in the ubuntu-nexus7 kernel, just waiting for it to actually get to the devices
<lardman|home> if one uses chroot then presumably the Android data won't be available?
<lardman|home> s/chroot/whatever method to change the location of root
<[mbm]> depends on the chroot
<[mbm]> one fun trick is pivot_root
 * lardman|home tries to remember the difference
<[mbm]> which technically only works on mount points
<[mbm]> pivot_root differs from chroot in that it's global, not just sub processes
<[mbm]> also it places the pervious root directory as a subdirectory of the new root
<lardman|home> I had to do that on the Galaxy Tab kernel to move from initrd to rootfs to boot Mer, but can't remember for the life of me now what the diff was
<lardman|home> ah yes, that sounds familiar
<[mbm]> so a common thing might be: mount /dev/root /target; pivot_root /target /initrd; umount /initrd
<Tassadar> I wanted to modify ubuntu as little as possible, so I just move the android to /media/*something* and then move in the ubuntu files :/
<[mbm]> normally you can't specify an argument to pivot_root that isn't a mount point
<[mbm]> which would make something like /media/ubuntu or /data/ubuntu annoying
<[mbm]> the workaround is amazingly simple though
<[mbm]> mount --bind /data/ubuntu /data/ubuntu
<[mbm]> and magically it's a mount point suitable for use with pivot_root
<Tassadar> would be great to get something like that into ubuntu)
<lardman|home> +1
<[mbm]> yeah, I want to see a nice dual boot solution
<[mbm]> bootloader is a different story
<Tassadar> also, mounting .img as root would be great, if that's even possible
<[mbm]> yep, that's easy
<Tassadar> do tell
<[mbm]> mount -o loop root.img /target; pivot_root /target /initrd; umount initrd
<[mbm]> as in, recompile the ubuntu kernel so that the initrd mounts the correct root device
<[mbm]> part I'm trying to figure out is if there's a better way to handle bootup than booting into a linux kernel which provides a kexec boot menu
<lardman|home> normal vs recovery partitions?
<Tassadar> then you don't even have the boot menu
<lardman|home> or you want to leave the recovery partition functionality?
<[mbm]> yeah, could put the ubuntu kernel on the recovery partition but then you lsoe access to recovery
<[mbm]> would be nice if there was a 3rd partition and entry on the existing boot menu
<Tassadar> would be nice if the bootloader was open-source)
<lardman|home> :)
<[mbm]> yeah, that's the problem
<Tassadar> ...and we had nvflash, so that we could not brick it)
<[mbm]> frmo what I can tell the hardware is technically locked, and it's simply that unlocking tells the bootloader to ignore signature checks
<Tassadar> well, it is nvidia, so...
<lardman|home> Is the loss of the recovery partition such a problem - people installing this are going to be used to flashing things I'd expect
<[mbm]> not 100% certain on that first part though, don't know if nvflash is all that's needed or if the hardware does a signature check on the botloader
<[mbm]> yeah, but it's more of an annoyance thing; if I'm dual booting and I get an ota update to android, it'll download to the /cache partition and then reboot into recovery with the /cache/recovery/command set to automatically apply it
<Tassadar> lardman|home: I don't really see the point in using recovery partition once the kexec-hardboot is there
<lardman|home> ah, I didn't realise that was how it worked
<lardman|home> Tassadar: sure
<[mbm]> Tassadar: I know what kexec is, but what's the "hardboot" part?
<Tassadar> on most android devices, normal kexec just freezes
<Tassadar> due to drivers not properly initializing, probably
<[mbm]> well yeah, arm kexec has traditionally been a bit dodgy
<Tassadar> so "kexec-hardboot" patch was made, which does full hw restart of the device between the boot
<Tassadar> basically "fastboot boot" without the fastboot
<Tassadar> gimme a second, I'll find a link to the original patch...
<[mbm]> that's interesting; any idea how it manages to avoid going into the bootloader after resetting everything?
 * [mbm] grabs some lunch (bbl)
<Tassadar> kexec -e saves some info to RAM (some location where it does not get overwritten on reboot), then reboots normaly
<Tassadar> the same kernel checks for that info in early state of boot (in the decompressor), and if it is there, it decompresses the kernel from RAM
<Tassadar> ...that is how I understand it
<Tassadar> http://forum.xda-developers.com/showthread.php?t=1266827 here is the original patch
<lardman|home> thanks
<Tassadar> the con is that it needs 2 small patches in the "guest" kernel, the one which is being booted with kexec
<lardman|home> So the plan would be to place the Ubuntu kernel in the boot partition and need to patch the Android kernel?
<Tassadar> both kernels must be patches
<Tassadar> *patched
<lardman|home> sure, but which is booted?
<lardman|home> (first)
<Tassadar> I would recommend the android kernel, since it does not get updated so often and can be easily patched.
<lardman|home> fine, that makes sense, and presumably one would be able to perform a binary patch on the kernel from Android userspace?
<Tassadar> wau
<Tassadar> you just want to make it difficult :D
<lardman|home> to avoid needing to flash a new kernel whenever an update occurs
<lardman|home> re this post, any ideas on what the Ubuntu image does on first boot that might break something if it's in the recovery partition: http://forum.xda-developers.com/showthread.php?t=1266827
 * lardman|home goes to look at the image now it's downloaded
<Tassadar> well it flashes boot image
<Tassadar> which it also does on every kernel/initrd update
<Tassadar> so you have to disable that
<lardman|home> Not the updater script that runs on the desktop, the image running on the device flashes the boot image too>
<lardman|home> ?
<lardman|home> s/updater/installer
<Tassadar> yes
<Tassadar> 12.10 removes the tarball-installer image
<Tassadar> and 13.04 will change kernel cmdline during installation
<Tassadar> *tarball-installer package
<lardman|home> and it can't know where the running kernel is located I guess?
<Tassadar> no
<lardman|home> ok, well at least that explains the need that chap had to reflash the Android kernel
<lardman|home> Is the move to using kexec imminent, or is it worth just hacking together a dual boot setup for the time being?
<Tassadar> I dunno where the kernel with patches gets to repositories, so...
<Tassadar> *when..ohmygodineedsomesleep
<lardman|home> :) I was just trying to parse that correctly
 * [mbm] reads over the kexec threads
<[mbm]> guessing that the stock recovery kernel isn't patched for hardboot support?
<Tassadar> nope
<[mbm]> :/
<[mbm]> was hoping it would be as easy as replacing recovery with a kexec menu and then using kexec-hardboot to switch between ubuntu and recovery
<[mbm]> though there's also the pesky problem of /system/etc/install-recovery.sh which takes the existing "boot" kernel, applies a patch and writes it to recovery
<[mbm]> stupid script gets installed by an ota and run every subsequent boot
<Tassadar> anyway, heres CM10 kernel with applied kexec-harboot patch: https://github.com/Tasssadar/android_kernel_asus_grouper/commits/kexec-clean
<Tassadar> I even submitted it for review to cyanogenmod, hope it get's there
<marvin24> ogra_: can we create some nvidia-tegra-dev package with headers needed to compile the gstreamer plugins?
<marvin24> I don't want to copy them into the source, because I feal they belong to the drivers package
<marvin24> ogra-cb_: ^^^
<marvin24> basicly these ones (without the OMX_*) https://gitorious.org/nvtegra-gst/gstomx/trees/master/nv_headers
<mjrosenb> ooompf
<mjrosenb> I installed ubuntu on my chromebook using the absurd script that repartitons the disk, and fetches a bunch of tarballs
<mjrosenb> and its kernel wasn't compiled by ubuntu, was it?
<mjrosenb> I bet it just stole cros' kernel
<mjrosenb> which explains why I can't install perf on it :/
#ubuntu-arm 2012-12-01
<hrw> mjrosenb: building kernel for chromebook is not rocket science
<hrw> https://launchpad.net/chromebook-arm - for Chromebook users/hackers
<tassadar_> does anyone know if there is a package made from http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-nexus7.git;a=summary ?
<infinity> tassadar_: Yes.
<infinity> tassadar_: https://launchpad.net/ubuntu/+source/linux-nexus7
<tassadar_> hmm, packages.ubuntu.com did not find that one
<tassadar_> I suppose that is the kernel in raring image, and will not get into 12.10..?
<infinity> Right.
<infinity> No reason to backport it.
<infinity> This is all for development purposes, after all.
<tassadar_> yeah, that means I'll have to use the raring image for multi-boot
<infinity> And packages.ubuntu.com only indexes amd64 and i386, which is why you wouldn't find it, being an armhf-only kernel.
<tassadar_> haaa
<tassadar_> I rebooted to recovery from kernelspace
<tassadar_> good :)
<asiekierka> ugh, my tf101 seems to be a paperweight now
<asiekierka> can't get into APX, read -71 everywhere in dmesg
<RaYmAn> it's usually a problem with cable and/or host usb port
<RaYmAn> it's rather..sensitive.
<RaYmAn> APX mode itself can't really break, so it has to be a hardware issue. (also, is it nvflash or wheelie failing?)
<asiekierka> RaYmAn: nvflash
<asiekierka> i have a B50
<asiekierka> as I said, I believe it's because it ran out of battery power during nvflashing
<asiekierka> in the middle of it, installing the large system image
<RaYmAn> that doesn't matter
<asiekierka> it SHOULD technically run the bootloader, though
<asiekierka> that's odd
<RaYmAn> APX mode is in bootrom
<RaYmAn> you can't break it
<asiekierka> i know
<asiekierka> APX mode boots up but it quickly shuts down
<asiekierka> as i said, seems it doesn't want to charge
<asiekierka> thus connecting it to USB 3.0 may help
<asiekierka> then i can both charge and APX
<RaYmAn> not really
<RaYmAn> it's a bit of a myth
<RaYmAn> the charger switches to 15v to charge properly, which usb 3.0 certainly doesn't provide :P
<asiekierka> so what should I do?
<asiekierka> by charge i mean just enough to boot the thing up
<asiekierka> so i can get into APX and make it run reasonably
<asiekierka> the dock does charge, sadly i can't tell if the tablet does
<asiekierka> all i can tell is that it partially boots into APX
<RaYmAn> let it fully run out of battery
<asiekierka> already done
<asiekierka> at least twice
<RaYmAn> then plug it into the charger and let it charge for a day or so
<asiekierka> left it by itself for a week
<asiekierka> oh, that
<asiekierka> hmm
<asiekierka> okay
<asiekierka> http://paste.ubuntu.com/1401724/
<asiekierka> here's what Linux says
<RaYmAn> probably battery issue I guess
<asiekierka> i can tell
<asiekierka> should i charge the dock as well?
<RaYmAn> doesn't really matter - you shouldn't nvflash through dock anyways
<asiekierka> the same happens when i nvflash dockless
<RaYmAn> it refuses to enter nvflash and stuff if battery is too low, even if it's charging
<asiekierka> yes, i noticed
<asiekierka> what i can tell from the logs is:
<asiekierka> - the PC detects a new USB device
<asiekierka> - the tablet either refuses to boot up properly or runs out of the minimal amount of battery
<asiekierka> - the PC does that again
<asiekierka> - same happens
<asiekierka> - then the tablet stops accepting any data from the PC
<RaYmAn> did you leave it charging for a long time? and by long I do mean like 24 hours at least (in real charger)
<asiekierka> IIRC yes
<asiekierka> as i said, the main problem is that it ran out of battery in the middle of APXing
<RaYmAn> yeah, that's not really relevant
<asiekierka> okay, now that's odd
<asiekierka> it stopped accepting APX the moment that happened, even if i tried to recharge
<asiekierka> i wonder if the battery's just dead
<RaYmAn> APX mode doesn't care about the eMMC at all
<RaYmAn> so you can half-flash anything you want and it'll still be fixable
<RaYmAn> so I'd say either cable or battery
<RaYmAn> It's probably just a freak coincidence
<davecheney> i hate sd cards
<davecheney> lucky(~/Downloads) % sudo dd if=boot.img-serial of=/dev/mmcblk0
<davecheney> 31457792 bytes (31 MB) copied, 10.9471 s, 2.9 MB/s
<davecheney> lucky(~/Downloads) % sudo dd if=boot.img-serial of=/dev/mmcblk0
<davecheney> 31457792 bytes (31 MB) copied, 12.6877 s, 2.5 MB/s
<davecheney> top one is a $5 no name sdcard I got at the supermarket
<davecheney> bottom one is a top spec fujistu class 10
<RaYmAn> try with a more suitable blocksize
<davecheney> does dd really default to 1 ?
<davecheney> this is for a pandaboard
<davecheney> which has a really slow sd interface
<RaYmAn> no,but that didn't mean the blocksize it uses it's well suited for sd
<davecheney> bs=1m, 31457792 bytes (31 MB) copied, 0.023563 s, 1.3 GB/s
<davecheney> somehow I don't think that is accurate
<davecheney> gah
<davecheney> too hot, too tired tonight
<lilstevie> davecheney, it is rather warm here too
<lilstevie> :/
<tassadar_> winter's beginning here)
<lilstevie> First day of summer here
#ubuntu-arm 2012-12-02
<davecheney> is their a quantal-server-armhf-image available ?
<davecheney> for omap4
<infinity> davecheney: http://releases.ubuntu.com/12.10/
<infinity> davecheney: Or, if you're after netboot images, http://cdimage.ubuntu.com/netboot/quantal/
<davecheney> infinity: i tried the netboot last night
<davecheney> it doesn't setup the uboot parition
<infinity> Sure it does.
<davecheney> nup
<infinity> It *is* the uBoot partition
<davecheney> right, but after you go through the installer
<infinity> The only way for that to fail is if you either repartition the card, or remove it.
<davecheney> the sdcard is just formatted like a usual quantal install
<infinity> Oh.  Yeah.  Don't install to the SD card.
<infinity> It's designed to install to other media.
<davecheney> infinity: shuld I start with precise and dist-uprade instead ?
<infinity> ...
<infinity> The installers are identical.
<infinity> Oh, unless you mean a precise preinstall.
<davecheney> as in, start with the precise sever omap4 image
<infinity> Why do you want to run from SD so badly?
<davecheney> 'cos I only have a panda
<infinity> ... and?
<davecheney> yeah, I guess I can use outboard usb
<infinity> I run all my Pandas from external media.  Makes them not suck. :P
<davecheney> the internal card is farqing slow
<davecheney> ok, that sounds like a plan
<infinity> Yes, this is why we don't officially support installing to SD anymore.
<infinity> It's an awful user experience.
<davecheney> use the netboot installer, install to the usb drive
<davecheney> then i need to adjust my uboot settings right ?
<infinity> (That said, if you use netboot and then tell the installer to "install to largest contiguous free space" instead of "entire disk", it might work)
<davecheney> or will the netboot installer do that for me ?
<infinity> No, it'll do everything right for you.
<davecheney> if i'm not an idiot an let it overwrite the card I just booted from :)
<infinity> Just select the external disk and "entire disk", and it'll do the right thing and rewrite the SD card.
<davecheney> okie dokes
<davecheney> thanks mate
<infinity> Even a USB thumb drive is a huge improvement over running from SD, but I do recommend an external hard drive (rotary is fine, SSD is a waste of money).
<lilstevie> SSDs are faster than USB
<davecheney> for all my machines they mount /home over nfs
<davecheney> so I only use the sdcard for /
<davecheney> and once everything is cached
<davecheney> it's usable
<lilstevie> hell even a lot of rotary disks have faster access times
<infinity> Oh, if you're doing things like that, then yeah, you might want to try installing to SD, I suppose.
<infinity> Like I said, we don't "officially" support it, but if you pick the "largest contiguous space" option instead of "entire disk", it may DTRT.
<infinity> It used to.  But I haven't tested that in a while.
<davecheney> i'd say usb ethernet and usb sata would be about as aweful
<davecheney> infinity: i'll try largest
<infinity> USB HDDs are ridiculously fast in comparison to SD, though, if you intend to do anything locally.
<infinity> (Also, SD cards kinda burn out and explode with heavy use, but if you're essentially using it read-only, that's not as big a deal)
<davecheney> infinity: btw, nexus 7 with lightdm shutdown is a pretty decent build host
<davecheney> but again, mount your home from somewhere else
<davecheney> that is an expensive flash card
<infinity> Building over networks doesn't excite me terribly. :/
<infinity> If I could both charge it *and* have a USB HDD plugged in at the same time, I'd love it.
<davecheney> that would rquire some kind of bi sexual usb cable
<infinity> Exactly.
 * davecheney shudders 
<infinity> I have enough build hosts lying around here, though.
<infinity> And still considering jumping on the Chromebook bandwagon.
<davecheney> if I could get someone to mule me one from the states, us!
<davecheney> yes!
<davecheney> i have the reddies in my hot little hand
<davecheney> but you can't buy the buggers in AU
<infinity> Yeah, can't buy them in Canada either, but getting friends to ship across that border is less hassle.
<davecheney> i'll keep an eye out for folks making the trip across the ocean
<davecheney> but I suspect it'll be UDS-R before I can get one
<infinity> And I usually buy all my laptops in the US, just due to the fact that they always try to fleece us on local sales.
<infinity> Our dollars are basically at parity right now, but everything's mysteriously 30% more expensive here.
<davecheney> infinity: yes, the AUD is kicking the greenback's arse
<davecheney> but for some reason there is a 10-20% living in australia tax
<infinity> davecheney: Your tax makes some sense.  People have to send stuff to you in the middle of nowhere.
<davecheney> nah, that is bullshit
<infinity> davecheney: In my case, everything ships from the same warehouses (often, ironically, ones in Canada).
<davecheney> taiwan is a lot closer to AU than Canada
<davecheney> samsung are korean, i think
<infinity> davecheney: Yes, but you're a population of 20M.  We're 350M.
<infinity> davecheney: That *does* make a difference when it comes to how you can or can't ship bulk.
<davecheney> 22million i'll have you know, we've been busy
<davecheney> yeah, i'm just whinging
<infinity> (I know it sucks, I used to live in Melbourne(
<infinity> )
<infinity> The trick was to have friends visit.  Or travel lots.
<infinity> And always get stuff on the outside. :P
<infinity> Except lambs.
<davecheney> infinity: i've also got hold of an imx.53
<davecheney> how do you run the sata port on there
<davecheney> considering there is no power header
<infinity> I have mine plugged into an internal->eSata adaptor, and have it plugged into an eSATA drive in a caddy.
<davecheney> ahh, right, so your getting the power from the caddies wall wart
 * infinity nods.
<infinity> That's the only sane way to get power to anything on these boards.
<infinity> Same for USB drives.
<davecheney> yup
<infinity> Driving them from the USB hub will end in tears.
<davecheney> oh no, think of the children!
<davecheney> infinity: doing largest looks like it'll work
<davecheney> it started at partition 2 this time
<davecheney> thanks for the tip
<infinity> Yeah, this could all be made more elegant, but... The biggest consumers of netboot on omap/omap4 boards also happen to be people who preseed and do their own twisted magic anyway.
<infinity> As such, it never became much of a priority to make this more user-friendly.
<infinity> Or friendly at all. :P
<davecheney> i think it's pretty decent
 * davecheney has been playing with freebsd/arm
<davecheney> that is _not_ user friendly
<infinity> Oh, sure, we're more friendly than most everyone else.  But I hold myself to a higher standard than that. :P
 * davecheney nods
<infinity> Someone really needs to send me a Beagle xM.
<infinity> This C4 I'm testing on makes me want to kick puppies.
<infinity> I bet I could have kidnapped a bucket of XMs when I was in London last.  And I forgot.  Drat.
<davecheney> c4 ?
<davecheney> "when i doubt, c4!"
<infinity> davecheney: Ancient beaglboard model, 750MHz, 256MB of RAM.
<lilstevie> ew
<infinity> davecheney: Not the most pleasant system to be testing my omap3 fixes on.
<davecheney> oh sadface
<davecheney> can't you use the loco ?
<infinity> To test omap3 stuff?  That would be a cute trick.
<infinity> Given that it's a different SoC. :)
<davecheney> oh, sorry
<davecheney> i keep forgetting that it's not Ti
<infinity> Heh.
<davecheney> but then again, there won't be any more OMAP boards now
<davecheney> so i'd better get use to that
<infinity> And I was so looking forward to the Panda5.
<davecheney> have they just given up
<infinity> No.
<davecheney> i heard they were selling the OMAP5 rights
<davecheney> or they were at least up for sale
<infinity> I'm actually not sure of the current state of affairs.
<davecheney> there is also the exyijis
<davecheney> i have no idea how to spell that
<davecheney> the quad cortex-a9
<davecheney> from samsung
<infinity> Exynos.
<davecheney> yes
<davecheney> ok, gotta fly, thanks for your help
<davecheney> will report back when the net install is done
<tassadar_> Will 12.10 version of ubuntu for nexus 7 get any updates or not?
<xenome> does midori not support html5 anymore?  It seems to work great under the angstrom distribution
#ubuntu-arm 2013-11-25
<IamTrying> I have this Beagle Board which has a micro flash card. Now how can i install Ubuntu 13. or 12. on it please?
<IamTrying> Hello? What happen to the Ubuntu ARM community. Dead, Silent !!!!!! getting worried
<ogra_> most efforts moved to #ubuntu-touch ...
<ogra_> (beyond the highperformance arm clusetr stuff ... )
<ogra_> *cluster
<IamTrying> OK - i am leaving ubuntu-arm then ogra_ , no community no fun man its like walking alone in desert.
<IamTrying> Thank you ogra_
<ogra_> what kind of beagleboard is that ? there are installer images for the XM and the C series iirc
<ogra_> we never really officially dd omap3 stuff though
<IamTrying> ogra_, http://beagleboard.org/Products/BeagleBone%20Black  - i bought this just to install Ubuntu on it
<IamTrying> But i have no idea how to install it
<ogra_> yeah, then talk to the beagle community in #beagle ...
<IamTrying> OK - Thank you ogra_
<ogra_> there are no ubuntu images for anything after the XM
<k1l> IamTrying: see http://elinux.org/BeagleBoardUbuntu
<ogra_> yeah, robert nelson always provided homebewed images
<ogra_> brewed
<IamTrying> WOW - k1l Ubuntu 13.10 ???
<IamTrying> Man i love it, thank you
<k1l> IamTrying: and be aware, that the arm community is not that beginner community like the desktop stuff is. you will need to read and learn alot of things and you will not get a hand by hand guide all the time. just to warn you so you are not disappointed that fast
<IamTrying> OK - Guru k1l
<TooLmaN> Hi guys.  I'm looking for resources for making an ARM Ubuntu image for older Wyse thin clients.  Can anyone point me in the right direction?  Thanks in advance
<ogra_> you could start from ubuntu-core ...
<TooLmaN> ogra:  I'll check out core.  These TCs are 1GB CPU, 1GB RAM, 1GB flash.  I have PuppyLinux running on it but I want Ubuntu.  Thanks
<ogra_> http://wiki.ubuntu.com/Core
#ubuntu-arm 2013-11-27
<oliver_> anyone using cubox?
<Timmy> hey guys, I have some questions which may be so stupid. so please excuse me and help me find my answers kuz I could not find them.
<Timmy> Can I design my ARM board and install ubuntu or any other ARM linux on it?
<k1l> ubuntu needs armv7 at least
#ubuntu-arm 2013-12-01
<bhalu> how to build custom images for arm board
<bhalu> ?
<Ignacio> Hi
<Ignacio> I'm looking for this package in arm
<Ignacio> http://packages.ubuntu.com/raring/wkhtmltopdf
<Ignacio> It's posible obtain the *.deb ?
<Ignacio>  test
<Ignacio> test
<phh> failed
<Ignacio> haha.
#ubuntu-arm 2014-11-24
<koot>  Is there a place I can search the ubuntu arm repositories before installing??
<applepi> hi all..  I've got an armhf core image extracted that I can qemu into and I'm trying to get networking working so that I can apt-get and set up some things, but for some reason it isn't working, even though I'm doing what I've done for my other image rootfs,
<applepi> mount bind /dev, /proc, and /sys to the image dev, proc, and sys, and chroot in..
#ubuntu-arm 2015-11-25
<genii> I've been working on getting Ubuntu onto some OMAP4470 based tablets here, Texas Instruments recommends using rootstock to create the filesystem, but I can't seem to find it anyplace ( according to them it's provided by qemu but I have qemu installed) and searching at packages.ubuntu.com produces no result. Was it superceded by some other method?
<ogra_> rootstock is long dead ...
<ogra_> but you can find the source on launchpad
<ogra_> https://launchpad.net/project-rootstock
<ogra_> (i assume you will need to fix issues if you try to build something newer with it)
<ogra_> there is a successor but i worte that mainly for touch, not for normal rootfs builds, so that wont help much
<ogra_> https://launchpad.net/project-rootstock-ng
<genii> ogra_: Thanks for the fast reply. What is the preferred method then to accomplish something like what is described in the reply of https://e2e.ti.com/support/omap/f/849/t/317605
<ogra_> i'd start from http://cdimage.ubuntu.com/ubuntu-core/daily/current/
<ogra_> that givey you a minimal rootfs
<ogra_> *gives
 * genii investigates
#ubuntu-arm 2015-11-27
<JerryS> Hi, all.  I'm looking for current instructions on how to build an armhf boot image.
<JerryS> This needs to run under QEMU.
<JerryS> I have the system cross-compiled, but am lost on how to create the boot image.
<JerryS> I'm not finding any good current instructions on the web.
<JerryS> Can anyone give me a lead?
#ubuntu-arm 2015-11-29
<flyn4x4web> hello room, I am having some problems today trying to update and upgrade my banana-pi running Ubuntu 15.04. seems like a connectivity issue. Do anyone know of more reliable server to use other than ports.ubuntu.com
#ubuntu-arm 2016-12-01
<djonas> Hello everyone
<djonas> Need some help installing Qt on my Ubuntu for Crosscompiling
<djonas> http://askubuntu.com/q/855697/625763
<djonas> Install cross-compiling Qt failed: fatal error: xcb/xinerama.h: No such file or directory
