[01:25] <infinity> janimo: I'd assume it's because we moved the toolchain to ARMv5, but perhaps haven't told GHC about it.
[01:25] <infinity> janimo: If you don't have the time to poke it, I can.
[01:30] <infinity> janimo: My suspicion seems to be confirmed by the build log.  Grabbing the source now to have a look.
[01:32] <twb> Don't forget you can ask #debian-haskell (OFTC) for advice re the ghc side of things
[01:33] <suihkulokki> ubuntu armel is armv5 again?
[01:38] <infinity> suihkulokki: SOrt of.
[01:38] <infinity> twb: I suspect it's actuall llvm that needs some love.  Or maybe ghc just needs a violent re-bootstrap.
[01:39] <twb> Last time I looked (karmic?) GHC on arm went via C
[01:39] <twb> Didn't know they had transitioned to llvm
[01:40] <twb> Oh and (at least at the time) ghc didn't support arm, really, it was just the debian haskell team making it kinda-work
[01:56] <suihkulokki> infinity: you need to update the topic then :)
[02:11] <hrw> suihkulokki: toolchain is armv5 but that does not mean that ubuntu/armel is armv5 again
[02:11] <hrw> suihkulokki: no one rebuilt whole archive for it
[02:25] <twb> What does "toolchain is armv5" mean?  That just those packages (presumably gcc, ld, etc) are compiled to run on armv5, though packages compiled WITH them target armv7?
[02:40] <hrw> twb: right
[02:41] <hrw> twb: ubuntu/armel was armv7 so most of packages still are. new ones will be armv5
[02:44] <int_ua> Hi. Looks like we have a newer somewhat stable kernel for the Nokia N900. Can someone help with packaging it and publishing on some server, better in the official repository?
[02:47] <twb> hrw: why the backflip?  Just because of raspberry?
[02:49] <suihkulokki> twb: there is now armhf so having two armv7 ports doesn't make much sense
[02:52] <twb> Oh.
[02:52] <hrw> twb: who care about r/pi?
[02:53] <twb> hrw: exactly
[02:56] <twb> armhf branch isn't mentioned anywhere on https://wiki.ubuntu.com/ARM btw
[03:01] <jackh> rasberry is ARMv5
[03:01] <infinity> jackh: It's v6.
[03:02] <jackh> twb: you mean ubunbu willl support that pi?
[03:02] <infinity> twb: Hrm, wiki/ARM seems pretty out of date in general.
[03:02] <jackh> infinity: ok, thanks for correct me
[03:02] <infinity> jackh: We're making no such commitment.
[03:02] <infinity> jackh: If we don't kill the armel port entirely, it might end up supporting the Pi, but that's still up in the air.
[03:04] <jackh> infinity: seems lot of work of packaging, testing, fixing?
[03:06] <infinity> jackh: Right now, we're just doing an organic/lazy rebuild.  But, like I said, we may still drop the port entirely, so no promises.
[03:06] <jackh> infinity: seems not many devices and dev-boards are supported by ubuntu now
[03:07] <jackh> infinity: i plan to do some work to support some of them
[03:07] <infinity> omap, omap4, mx53, ac100, plus all the boards that Linaro ships kernels for...
[03:07] <infinity> We have no real interest in building 50 images for every possible target.
[03:08] <int_ua> jackh: what about N900?
[03:08] <jackh> infinity: as you know they are too expensive, not suitable for young guys to buy
[03:08] <jackh> infinity: i am try to do some on A8 systems, which is very cheap here
[03:08] <infinity> jackh: 200 USD is "expensive"?  My, how times have changed.
[03:09] <jackh> infinity: Pi is 25bugs, you know that
[03:09] <infinity> Yes, but it's also not something you want to run a general prupose OS on.
[03:10] <infinity> An Ubuntu desktop wouldn't actually boot on it even if we were v6.
[03:10] <jackh> infinity: also hdmi is not pop here, i dont think they have hdmi tv
[03:12] <jackh> infinity: so i will do the things from the minimal rootfs and adds things on, if i meet any problem, i will disturb you:)
[03:16] <twb> infinity: these plans/changes will be set in stone as at the next release?
[03:17] <infinity> twb: It's more about if someone wants to sponsor the port.  Canonical's not really keen on doing armel for free.
[03:18] <twb> Nod.
[03:18] <twb> I was just confused because I thought it had already been decided (like, two releases ago) that Ubuntu's armel was gonna be v7 and HF and the only arm port Ubuntu had
[03:19] <infinity> ..?
[03:19] <infinity> armel was never going to be HF.
[03:19] <infinity> Hence armhf.
[03:19] <twb> I guess I was misinformed
[03:19] <twb> Or rather, I misunderstood
[03:19] <suihkulokki> I guess twb is confusing hf with softfloat abi vs hf abi
[03:19] <twb> I'll STFU now...
[03:20] <suihkulokki> it is confusing, no need to feel shame :P
[03:21] <jackh> hmm, infinity: suihkulokki: hf is hard floating, abi uses some mix of soft and hard floating, right?
[03:21] <twb> In my head "hf" means you must have a hardware FPU
[03:22] <infinity> Yeah, that's not what it means.
[03:22] <twb> Has someone written this stuff down somewhere?  If so I'll just go read that
[03:22] <infinity> soft is software FP, softfp is hardware FP, but soft's calling conventions, hard is hardware FP, and using a new calling convention that uses the VFP registers.
[03:23] <infinity> soft ansd softfp are ABI-compatible, hard isn't.
[03:24] <twb> IOW softfp will work on either, and can use a hardware FPU, but will have minor overheads compared to hard?  Whereas soft will simply ignore any hardware FPU?
[03:24] <twb> Or does "hard" actually work without a hardware FPU?
[03:26] <jackh> twb: iow, hf seems like a small intruction set
[03:26] <jackh> twb: the instructions will ask for and get result from some hardware units
[03:28] <suihkulokki> only softfloat works if you do not have VFP
[03:28] <twb> OK
[03:29] <twb> I guess all I really care about is making sure I pick the best build for whatever hardware is in front of me
[03:30] <twb> (Where "best" balances performance and effort - e.g. maybe it is worth recompiling the kernel, but not the entire distro, for my specific unit.)
[03:31] <jackh> twb: sorry, i still dont get what you want to do
[03:31] <twb> jackh: buy a computer, then make it go SUPER FAST
[03:31] <twb> Don't worry about it, I'm just talking shit
[03:31] <jackh> twb: i got it
[03:32] <jackh> twb: but that's x86 stuff, nothing to do with this channel
[03:32] <twb> Er, not on arm boxes
[03:33] <twb> Although my tf101 is still running oneiric and android's crappy kernel because I am actually too lazy to do anyhting but talk
[05:25] <recur> anyone know how to get Xfbdev to load fonts?  My embedded device needs something nicer than the fixed font :D
[05:48] <twb> There are broadly two font subsystems; the "x font system", which deals with bitmap fonts, and xft, which deals with outline fonts.
[05:49] <twb> GTK2/3 and Qt3/4 are xft-based; almost everything is.  xterm uses xft if you say e.g. "xterm -fa monospace"
[05:50] <twb> MOST apps that use xft, use a second library "fontconfig" to turn a logical font name like "Sans 12" into the path to a font file.
[05:50] <twb> Anyway, if it's an xft app I wouldn't expect anything special to be needed on the X server side, it's all X app side
[05:52] <recur> ohh cool
[05:52] <recur> thanks two, this is good info
[05:52] <recur> er twb, stupid spellcorrect ;)
[05:54] <twb> Sigh.
[05:55] <twb> You're about the fifth person in the last month to do that; it seems that everyone decided to turn on spell-checking at the same time...
[05:55] <twb> It's probably a new "feature" in pidgin or whatever the hell is popular these days...
[05:56] <furan> stupid question. I am working on desktop ubuntu with libavcodec-52, but when I installed libavcodec on my arm device I got -53. Is there any way to install -52 + dev?
[05:56] <recur> I'm using Textual, it's disabled now :D
[05:57] <twb> furan: if both boxes are running the same release, they should have the same version
[05:58] <furan> they apparently aren't
[05:58] <LetoThe2nd> maybe ont the desktop box there's medibuntu or such.
[05:59] <twb> furan: back- or forward-porting is not something you should attempt unless you are an experienced packager
[06:00] <twb> And that goes double for installing stuff directly (i.e. "make; make install" rather than "apt-get install")
[06:00] <furan> desktop:Linux version 2.6.32-41-generic (buildd@vernadsky) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) ) #89-Ubuntu SMP Fri Apr 27 22:22:09 UTC 2012
[06:00] <furan> Linux version 3.2.0-psp7 (root@panda-a1-1gb) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu4) ) #1 Fri Apr 13 04:55:05 UTC 2012
[06:00] <furan> and that's the device
[06:00] <twb> furan: use lsb_release -a to check the relases, and look at "apt-cache policy" output to see if they have rogue package sources
[06:00] <twb> That sounds like lucid vs. precise
[06:01] <furan> hah, I guess I installed lucid instead of precise on my vmware instance
[06:01] <furan> thanks
[06:01] <furan> ugh now i've gotta change all my libavcodec stuff
[06:01] <furan> oh well
[06:01] <twb> it's better in the long run iMO
[06:08] <janimo> infinity, good to know you're on ghc then :)
[06:08] <janimo> also good to hear we try an armv5 armel flavour even if just experimenting
[11:26] <ogra_> hmpf, i guess that got swallowed by my reconnect
[11:26] <ogra_> janimo, any news about the new ac100 kernel ?
[11:26] <ogra_> (would be nice to have something for A1 the binary drivers work with ... which means at least 3.1)
[11:26] <janimo> ogra_, I will have a look, would be nice indeed. I did no check marvin24's tree in almost a month I think
[11:28] <ogra_> well, i'm using a self rolled 3.1 since the new binary driver came out
[11:28] <ogra_> despite the driver bugs it seems ot work just fine
[11:28] <janimo> ogra_, I still hope all tegra2 stuff gets mainlined for 3.6 and maybe catches 12.10 :)
[11:29] <ogra_> but you wanted to switch to 3.2 you said in the past, that will require somce signficant changes (devicetree)
[11:29] <ogra_> 3.6 would be nice but i wouldnt count on it
[11:30] <janimo> I wanted to switch to whichever kernel is least hassle to maitain :)
[11:30] <janimo> if possible as new as possible to be in line with ubuntu
[11:30] <ogra_> sure
[11:31] <lilstevie> ogra_: you don't have any issues with 3.1
[11:31] <ogra_> it would be nice to have working images for the quantal milestones though, since we have a policy that images have to work nowadays
[11:31] <ogra_> i dont, no
[11:31] <lilstevie> I still can't figure out what is causing my hang
[11:31] <ogra_> seems as stable as 3.0 was
[11:32] <lilstevie> as long as I break it is fine
[11:32] <ogra_> lilstevie, try removing plymouth
[11:33] <ogra_> (by removing the plymouth hooks and scripts from /usr/share/initramfs-tools and rebuilding the initrd)
[11:33] <lilstevie> when I ask it to remove plymouth it wants to remove everything
[11:33] <lilstevie> ah
[11:34] <ogra_> yeah, mountall needs libplymouth iirc
[11:35] <lilstevie> well waiting for bonnie++ to finish then I will try without plymouth
[11:38] <lilstevie> also gpower is being a little trigger happy with the dual battery
[11:43] <janimo> ogra_, btw IIRC you packaged the tegra armhf drivers right?
[11:43] <ogra_> http://people.canonical.com/~ogra/nvidia-tegra/
[11:43] <ogra_> waiting for a newer kernel before i upload to the archive
[11:44] <janimo> ogra_, ah they completely fail with old kernel, ok
[11:44] <janimo> both armel and armhf in there?
[11:44] <ogra_> nope, only armhf
[11:44] <janimo> or we drop armel completely for quantal
[11:45] <ogra_> still waiting for mgmt decision ... as it seems we will keep it around in teh oinfrastructure but not touch it at all
[11:45] <janimo> lilstevie, do you know what the status of mainlining tegra2 support is?
[11:46] <lilstevie> janimo: not good afaik
[11:53] <lilstevie> ogra_: removed the plymouth hook altogether from initramfs and it is still doing it
[11:53] <ogra_> try also disabling the upstart plymouth jobs in /etc/init
[11:54] <lilstevie> ok
[11:55] <ogra_> or make plymouth non executable or move it to .orig and macke /usr/bin/plymouth a link to /bin/true
[11:56] <ogra_> oh, and indeed, drop "splash" from the cmdline :)
[11:56] <lilstevie> I don't have splash on the cmdline
[12:05] <lilstevie> ogra_: symlinking plymouth and plymouthd with /bin/true worked
[12:06] <ogra_> must be some issue with tegrafb or so
[12:06] <lilstevie> probably
[12:06] <ogra_> i saw that too, but only on tegra devices with 3.1 and newer kernels
[12:06] <lilstevie> this is with 3.1
[12:07] <ogra_> ah, yeah
[12:07] <ogra_> i was told 3.2 would be better with that
[12:07] <lilstevie> hm
[15:54] <janimo> lilstevie, do you know if android and ubuntu can dual-boot on a tf101?
[15:55] <janimo> adn whether there are other than 3g hw differences between tf101 and tf101g?
[22:33] <lilstevie> janimo: depends how you mean by dual-boot
[22:34] <lilstevie> janimo: I do it at the cost of recovery, but we have recently started getting kexec and kexecboot working
[22:47] <lilstevie> janimo: as for the difference between the tf101 and tf101g; they are simple, 3G modem attached to mini pci-e port, and different sbk set in the cpu, the rest of the hardware is 100% identical