[04:46] <DanaG> [ 3840.406250] INFO: task apt-check:7226 blocked for more than 120 seconds.
[04:46] <DanaG> [ 3840.419738] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[04:49] <DanaG> How do you suppress login scripts?
[04:49] <DanaG> The stupid thing is hanging at login... and then timing out at 60 seconds.
[04:51] <DanaG> I enter my username, and it waits like 50 seconds before showing me the password prompt
[04:52] <DanaG> What is this stupid apt-check, anyway?  When I log in, I want to log in... not have it block forever on some update check.
[05:01] <DanaG> argh, had to reboot the thing.
[05:08] <DanaG> argh.
[06:03] <DanaG> hmm, I do still get that OOM on ureadahead.
[06:03] <DanaG> Maybe it's because I haverc.local start pulseaudio and deluged.
[06:03] <DanaG> no, wait, /var/lib/ureadahead/pack doesn't exist.
[06:08] <DanaG> hmm, it also oom kills mount.ntfs.
[06:08] <DanaG> I guess I have too much stuff running.
[06:09] <DanaG> hmm, now I'm pondering which would be more useful: one of the beagle XM boards, or one of those not-available-yet Marvell thingies?
[06:16] <DanaG> And will Marvell's stuff do compiz?  that's my definition of useful 3D. =þ
[06:46] <DanaG> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/466886
[06:46] <ubot2> Launchpad bug 466886 in network-manager (Ubuntu) ""No network connection" when IPv6 is enabled in Network Manager (affects: 12) (heat: 60)" [Undecided,New]
[06:46] <DanaG> er, not arm-specific.
[07:30] <DanaG> hmm, is rcn-ee around?
[07:43] <neure> hi
[07:45] <neure> after installing ubuntu-netbook.. in keyboard doesnt work
[07:45] <neure> nor mouse
[07:46] <neure> i can go to text console
[07:46] <neure> wait
[07:46] <neure> keyboard works
[07:46] <neure> mouse doesnt
[07:48] <neure> weird
[07:48] <neure> i had to switch it to other usb port on the hub
[07:48] <neure> now it works
[07:58] <neure> erm
[07:58] <neure> cpufreq-info says there is no driver :(
[08:00] <wv> Hello, I have ubuntu 10.04 installed on a IMX51
[08:00] <wv>  but want gnome to use a resolution of 1536x384
[08:00] <wv> for some reason it always jumps back to 1536x768
[08:00] <wv> Somebody knows how I can change this?
[08:01] <neure> i dont even know what imx51 is but on beagleboard that i have the resolution is set in the bootloader bootargs
[08:02] <wv> freescale's cortex based processor
[08:02] <neure> ok
[08:02] <neure> does it have some sort of boot loader?
[08:02] <wv> yes, redboot
[08:03] <neure> ok, i dont  know that one either
[08:03] <neure> but it is likely that you may need to provide resolution at boot time
[08:04] <wv> well, case is, I can change the resolution at runtime
[08:04] <wv> via fbset
[08:04] <wv> so my output resolution is already 1536x384
[08:04] <neure> but..?
[08:05] <wv> but the resolution gdm is using, is 1536x768
[08:05] <wv> so on my screen, I see only the upper part of my desktop environment
[08:07] <neure> i see
[08:07] <neure> no idea
[08:12] <wv> damn
[08:12] <hrw> morning
[08:38] <neure> hrw, know about cpufreq-utils?
[08:38] <neure> they worked on ångström but complain about missing driver on ubuntu
[08:43] <amitk> neure: cpufrequtils is not needed, we use ondemand governor by default and it is compiled in
[08:43] <amitk> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
[08:48] <neure> amitk, is there way to control to cpu frequency?
[08:49] <amitk> neure: switch the governor to a different one if you like
[08:49] <neure> amitk, cpu0 has on crash_notes
[08:49] <neure> only
[08:49] <neure> nothing else
[08:50] <neure> this is rcn_ee:s image
[08:50] <neure> maybe that could be missing some stuff
[08:50] <neure> ?
[08:50] <amitk> then _please_ ask him
[08:50] <neure> =)
[08:50] <neure> this was the only thing i was able to get running :/
[08:51] <neure> official doesnt support otg yet ehci is broken so what can i do
[08:51] <amitk> understood
[08:51] <neure> but yes, i will hang around here and wait
[08:51] <amitk> have you filed any bugs regarding ehci breakage?
[08:52] <neure> what should i report? "it is known that certain hardware is broken and ehci wont work"
[08:52] <amitk> you're using an older board?
[08:53] <neure> should i request that installer gives you a dialog "sorry, your hardware is known to be faulty, please wait until we support otg"
[08:53] <neure> C2
[08:53] <neure> not very old but ppl keep telling me it has usb issues
[08:53] <amitk> *shrug* can't help you then until OTG is fixed
[08:53] <neure> right
[08:53] <amitk> yes, it does
[08:53] <neure> what is the current status with otg?
[08:54] <neure> considering it is working in ångström and rcn-ee version, it should not be tough to get it to official
[08:54] <hrw> gcc-4.5 takes 3.5h on my x86-64...
[08:54] <neure> hrw, doing what?
[08:54] <neure> to build it?
[08:55] <neure> amitk, do you think it would be worth reporting a bug that installer should warn about known-to-be-broken hardware configurations?
[08:56] <amitk> neure: it can't hurt, talk to ogra (god of installers)
[08:56] <neure> ogra ping :)
[09:01] <markos_> could anyone help with this? (mono build on armel -mfloat-abi=hard), build phase succeeds, binary-arch fails:  http://paste.debian.net/75788/
[09:02] <markos_> package version mono-2.4.4~svn151842
[09:03] <markos_> same result with karmic version
[09:03] <hrw> neure: build package
[09:05] <neure> right :)
[09:07] <zyga> ogra: hi, did you get my message yesterday, the one about console colormap being broken on BB with 32bit fb
[09:09] <ogra> zyga, yes, i guess thats worth a bug
[09:09]  * ogra reads backlog
[09:09] <zyga> ogra, against linux package in lucid?
[09:09] <ogra> in lucid its linux-ti-omap iirc
[09:09] <ogra> in maverick its linux
[09:10]  * zyga wonders which release 'that' thing is based on (rolls eyes)
[09:10] <zyga> k, I think it's lucid
[09:11] <ogra> zyga, ask amitk i think its .33 with backports from .34
[09:11] <ogra> so its possible that the issues still show up in maverick (since the DSS patch might be the same)
[09:11] <amitk> zyga: in lucid, it is a 2.6.33 kernel
[09:12] <zyga> k
[09:12] <markos_> guys, also, are there any thoughts of providing native version of rootstock (ie one that doesnt' require an x86 box +qemu) to build the image?
[09:12] <zyga> I'll finish this install, take a photo and file a bug
[09:12] <ogra> neure, well, for lucid i wont change the installer and i'd rather fix the issues than popping up warnings :)
[09:12] <XorA|gone> markos_: isnt that called debootstrap :-)
[09:12] <ogra> markos_, look up debootstrap on the wiki :)
[09:13] <ogra> and read about chroot
[09:13] <markos_> or would you accept a patch?
[09:13]  * ogra always accepts patches if they dont break existing functionallity and are sanely coded ;)
[09:14] <ogra> amitk, do you know if the maverick kernel is supposed to support XM ?
[09:14] <markos_> uhm, that's not only what rootstock does, it also sets up various system stuff
[09:15] <markos_> ogra: at least that's the impression I get by reading its code ( I know about debootstrap, was a DD for 9 years :P)
[09:15] <ogra> markos_, indeed it does, though thats not really much ... loopback networking, fstab, system groups, default user, sudo from the top of my head
[09:16] <amitk> ogra: not yet, I haven't gotten around to looking at that yet (doing specs and all)
[09:17] <markos_> yeah, my idea was to prepare a native rootstock script (rootstock-native?) that works on just debootstrap + the extra stuff and send it over
[09:17] <ogra> amitk, k, x-loader and u-boot fully support it now (the omap3 packages i uploaded yesterday)
[09:17] <ogra> markos_, feel free, i'll happily add it
[09:18] <markos_> ogra: basically, i've rebuilt basic ubuntu-desktop karmic, using hardfp -instead of softfp- float-abi and would like to provide a couple of images as proof of concept -to see if the performance difference is worth the effort -imho it is, but i'd like to have numbers to base this
[09:18] <ogra> markos_, though to avoud code duplication it would be clever to make rootstock use that script in the VM, i.e. just split out the installer part
[09:18] <markos_> ogra: good idea
[09:19] <zyga> ogra: I sent you an image that shows the colors and something I'm not familiar with - it looks like a kernel oops (it has a backtrace) but it's not an oops ;-)
[09:20] <zyga> ogra, should I file a bug against that as well?
[09:20] <ogra> yes
[09:20] <ogra> and if you have a spare SD it would be cool to compare against maverick
[09:21] <ogra> (upgraded lucid, we dont have installer images yet)
[09:21] <markos_> ogra: in fact these days i'll set up a tiny arm-based compile-farm (8-9 nodes) to support this initiative, these will be Genesi EfikaMX boards (iMX515 based)
[09:21] <ogra> nice !
[09:21] <lool> markos_: wow you rebuilt ubuntu-desktop using hardfp?
[09:22] <lool> markos_: So you used gcc 4.5?
[09:22] <markos_> ~3k packages so far
[09:22] <lool> markos_: So you bootstrapped stuff by hand to build in the correct order?
[09:22] <markos_> no, codesourcery 2010q1-202 (gcc 4.4.1 +patches)
[09:22] <lool> or are you rebuilding multiple times
[09:22] <markos_> es
[09:22] <markos_> yes
[09:22] <markos_> I bootstrapped some stuff initially
[09:22] <markos_> then I rebuild pretty much everything -incl the basic stuff like gcc, eglibc, etc
[09:23] <lool> markos_: Do you have notes from your setup, and from the issues you faced?
[09:23] <neure> ogra, would it then be fix to refuse to use known-to-be-broken hardware?
[09:23] <markos_> it sure took a LOOONG time
[09:23] <ogra> neure, no, the fix would be to fix the breakage :) maverick is still young
[09:23] <markos_> lool: well, the biggest problem were the cyclic dependencies in the packages themselves
[09:23] <lool> markos_: https://blueprints.launchpad.net/ubuntu/+spec/arm-m-automated-bootstrap
[09:24] <markos_> lool: I stopped taking notes when the dependency cycle included too many packages :D
[09:24] <lool> markos_: I'm interested in even partial notes if you don't mind sharing them
[09:24] <markos_> lool: I still remember most of it
[09:25] <markos_> right now I'm stuck in gcj and mono
[09:25] <ogra> zyga, hmm, that page allocation failure looks like livecd related, i think plars saw something similar already but it didnt do any harm to the actual install process
[09:25] <zyga> ogra: ok, I'll file a bug about that anyway
[09:25] <ogra> not sure he filed a bug about it though
[09:25] <ogra> yeah
[09:26] <markos_> lool: unfortunately, it's a long way from becoming trully automated
[09:26] <lool> markos_: Yes, I think we need to start somewhere
[09:26] <lool> markos_: I'd like to provide a prototype resolving a particular cycle or a small set of cycles, and then proposing the concept to Debian/Ubuntu at large
[09:26] <markos_> lool: mind you, I started from a hardfp gentoo basic image
[09:26] <lool> aha
[09:27] <lool> markos_: So how did you keep the Debian and Gentoo bits isolated?
[09:27] <markos_> separate chroots
[09:28] <markos_> right now the basic system runs on softfp, and I had 2 chroots one gentoo-hardfp, and another with karmic
[09:28] <markos_> I built a couple of vital packages inside gentoo, like eglibc, bash, gcc, etc
[09:28] <lool> markos_: Please correct me: your process was something like: create a gentoo hardfp chroot, build build-essential packages by hand in it using CS compiler, setup a buildd using a compiler wrapper which calls into codesourcery instead of build-essential, build everything you can and resolve loops by hand
[09:29] <markos_> and dpkg -i --root=<karmic-hardfp-root> the packages
[09:29] <markos_> after a while, I could chroot in the karmic-hardfp dir and start building packages there
[09:30] <markos_> lool: actually I packaged codesourcery compiler using ubuntu's package and modifying it a bit, so right now I have gcc-4.4 codesourcery replacement packages
[09:30] <markos_> but yes, the loops were resolved by hand
[09:31] <lool> That's really cool because that's exactly how we envisioned people doing rebuilds to do it
[09:31] <lool> (replacing the gcc sources contents)
[09:31] <markos_> lool: I saved you the job :)
[09:31] <lool> well I'd rather say you proved our imagination right   ;-)
[09:31] <markos_> the only remaining thing right now is to provide the images somewhere
[09:31] <lool> markos_: So who do you do that for, will you share the resulting packages publicly?  :-)
[09:32] <markos_> Genesi
[09:32] <markos_> of course
[09:32] <lool> You work for Genesi?
[09:32] <markos_> yes, doing that and NEON stuff as well
[09:32] <lool> markos_: Tell me about the NEON stuff!  :-)
[09:34] <lool> markos_: I'm also curious on whether you had the chance to compare speed of hardfp versus softfp
[09:34] <markos_> lool: well, I only started doing that, some proof of concept NEON work went into the Eigen math library (it was easier for me as I had already done the altivec port some years ago)
[09:35] <lool> Too bad you actually had to use a Gentoo chroot too, the plan on our side was to cross-compile build-essential, but it's not easy because you have to bootstrap them
[09:35] <markos_> lool: now, I'm working on the neon libfreevec port and some 2D driver optimizations for the imx515 X driver
[09:35] <DanaG> Stupid Adobe:
[09:35] <DanaG>  openscreenproject.org tells me to download Flash plugin....
[09:35] <markos_> lool: yes, I didn't want that either, but I had no choice really
[09:35] <DanaG> on ARM.
[09:36] <lool> markos_: it certainly saved your time
[09:36] <DanaG> I wish somebody would make an ARM with an open GPU.
[09:36] <DanaG> Or at least, one with a GLX driver with texture_from_pixmap.
[09:36] <lool> markos_: Did you have to patch any sources for hardfp?
[09:36] <DanaG> Even nvidia is leagues above powervr in that rate.  Though, I'm not sure how Tegra is.
[09:36] <hrw> DanaG: ha! you did not told about gl in first line ;d
[09:37] <lool> markos_: We'd love helping you to merge the patches into Ubuntu proper
[09:37] <markos_> lool: actually I tried bootstraping it myself, but it was taking me too much time, and then someone (ssvb) published the gentoo tarball
[09:37] <markos_> lool: very few
[09:37] <markos_> i have them all here
[09:37] <lool> markos_: isn't it a problem that it uses the same gnu triplet?
[09:37] <markos_> well, apart from gcc which was a totally different package
[09:38] <markos_> well
[09:38] <markos_> they're totally incompatible
[09:38] <lool> markos_: It would be lovely if you could upload them somewhere, or open bugs or whatever
[09:38] <markos_> softfp/hardfp I mean
[09:38] <markos_> or rather
[09:38] <markos_> the binaries run
[09:38] <lool> markos_: I can host them if you don't have a web hosting location ready
[09:38] <markos_> but produce TOTALLY wrong results
[09:38] <lool> well you seem to have a debian account so you probably have a place already
[09:38] <markos_> I did, I 'm not a DD anymore
[09:38] <markos_> since 2008 :(
[09:39] <lool> Yeah, it says account locked
[09:39] <markos_> but space is no problem, net connection might be
[09:39] <wv> hello, I get a FBDEV(0): mode "1536x384_60" not found
[09:39] <lool> markos_: There is a lighter process to get an account reenabled BTW
[09:39] <zyga> ogra: https://bugs.edge.launchpad.net/ubuntu/+source/linux-ti-omap/+bug/588638
[09:39] <ubot2> Launchpad bug 588638 in linux-ti-omap (Ubuntu) "console colormap is wrong when using 32bit framebuffer (affects: 1)" [Undecided,New]
[09:39] <wv> although it's added to /etc/fb.modes
[09:39] <zumbi> lool: markos_ is coming to dc10 :)
[09:39] <wv> first thing it states before is: "checking modes against framebuffer device"
[09:39] <lool> markos_: I find it a bit scary that the binaries will be run
[09:39] <markos_> zumbi: that's not certain yet :)
[09:39] <zumbi> markos_: did not you registered?
[09:39] <lool> markos_: Anyway, I think we need a new debian architecture name for such a port
[09:39] <markos_> lool: yes, this is why it must be a separate tree
[09:40] <lool> ack
[09:40] <ogra> zyga, we used to subscribe ubuntu-armel and tag arm bugs with the armel tag in the past ....
[09:40] <markos_> zumbi: will do, I want to discuss with Genesi first
[09:40] <zumbi> lool: armfp?
[09:40] <markos_> zumbi: armelfp probably
[09:40] <lool> zumbi: I was thinking armhf rather
[09:40] <ogra> lool, do you know if there is a new practise ? ^^^
[09:40] <zyga> ogra, and now? should I do the same?
[09:40] <ogra> else i would like us to go on with that behavior
[09:40] <lool> markos_: "arm" was little endian as well, it would be shorter
[09:41] <ogra> zyga, i dont know if the policies changed with the new team
[09:41] <markos_> lool: I think it's worth the effort basically
[09:41] <ogra> zyga, thats why i asked lool  :)
[09:41] <zumbi> markos_: if you really want to attend dc10 is important you register soon as reconfirmation period has started and it is over by june 10th
[09:41] <markos_> anyway, I have a DSL 24/1 here, it can work to get the stuff fast to a server
[09:41] <ogra> zyga, essentially its makes searching for arm bugs easier
[09:41] <lool> ogra: we didn't change policies, but I dont think everybody is aware of these best practices
[09:41] <ogra> lool, ok, we should spread them then
[09:41] <markos_> zumbi: I have 8 days left then :D
[09:41] <lool> ogra: it's something the mobile team did, but wasn't really communicated at large
[09:41] <ogra> lool, right
[09:41] <lool> markos_: I ceratinly agree it's worth the effort
[09:42] <zyga> lool, ogra, so adding tags and subscribing teams is best practice currently, correct?
[09:42] <zumbi> markos_: but I need to provide you with accomodation which you are already late (since April 15th)
[09:42] <lool> markos_: So do you think we should actually use a different GNU triplet?
[09:42] <ogra> if we didnt change them we should communicate it, if your team changed it the mobile team should know :)
[09:42] <ogra> zyga, yes
[09:42] <lool> currently I think it's still arm-linux-gnueabi for hard-float
[09:42] <ogra> zyga, ubuntu-armel and the armel tag
[09:42] <zyga> thanks
[09:42] <lool> zumbi: yes, tag it armel and sub ~ubuntu-armel
[09:42] <markos_> lool: indeed, well, i'm not sure about that
[09:43] <hrw> lool: but armelhf shows cleanly that this is armel based just in case someone will wonder is it eabi still
[09:43] <ogra> zyga, only subscribe ubuntu-areml (dont assign)
[09:43] <lool> zumbi: Tag it armel if it's specific to armel, subscribe the team if that sounds like an interesting bug for the armel porters
[09:43] <zyga> right
[09:43] <markos_> it's not exactly a subarch either, i'm not sure how to categorize it
[09:44] <lool> markos_: The same *spec* covers the two subcases, but the *abi* is actually different, so I think we should get that fixed to use a different triplet, but I suspect it's a rather painful process for everybody
[09:44]  * lool notes to bring that up with CS
[09:45] <lool> hrw: armeb doesn't tell you anything about EABI though
[09:45] <markos_> it is rather painful yeah :)
[09:45] <lool> markos_: So your goal is to build all of Ubuntu main + universe, or just main or...?
[09:45] <lool> markos_: How do you define your project as successful?
[09:46] <hrw> lool: armeb for me is "arm BE" so for debian based it mean oabi to me
[09:48] <markos_> lool: well, for now, main will suffice, soon -the extra nodes will arrive these days, so I'll have the cpu power to maintain this at least now
[09:48] <lool> hrw: You can have BE and EABI
[09:48] <lool> hrw: in fact, "If a bigendian arm EABI port will be created, it will be called "armeb", and it will replace the previous oldabi-based "armeb" port effort. "
[09:48] <hrw> lool: I know
[09:49] <markos_> lool: as for success, well I expect quite a measurable performance improvement esp in 3D or fp-intensive apps
[09:49] <hrw> good to know
[09:50] <markos_> lool: hardfp supposedly saves 20 cycles per function call, so esp in 3d or any other app that calls too many small functions with fp arguments, it *should* make a difference
[09:52] <lool> markos_: in fact it's 20 cycles per load / store of a single vfp register IIRC
[09:52] <lool> So it could be much more
[09:52] <markos_> hm, yes, you're right :)
[09:52] <lool> (or perhaps it's all vfp registers, in which case I'm confused)
[09:54] <markos_> lool: right now the only setback to providing the images, is mono -and to a lesser extent java. gnome-applets (part of ubuntu-desktop) depends eventually from mono which breaks here
[09:54] <markos_> apart from that, I could provide ubuntu-minimal and ubuntu-standard right now even
[09:54] <markos_> but I don't have an ubuntu x86 box (yet) :)
[09:55] <lool> markos_: mono doesn't build with hard-float, or it's broken at runtime?
[09:55] <markos_> but, I could make my local mirror public and one of you could run rootstock :)
[09:55] <markos_> the build breaks, in particular, binary-arch phase: http://paste.debian.net/75788/
[09:56] <lool> markos_: That would be interesting; I'm mostly interested in benchmarks on the same hardware + source package version between softfp and hardfp; I'd like to prioritize this new port over our other devs
[09:57] <lool> make[2]: *** [build/deps/basic-profile-check.exe] Error 1
[09:57] <lool> I dont see that error
[09:57] <lool> markos_: And we could start integrating the patches ASAP too
[09:57] <markos_> lool: they're not that many
[09:57] <lool> markos_: Still!  :-0
[09:58] <markos_> lool: the most important change is the compiler
[09:58] <markos_> it would either have to be gcc-4.5 -which I haven't tested- or codesourcery
[09:58] <lool> Ack
[09:58] <markos_> the current 4.4 in ubuntu doesnt' support hardfp, at least it didn't a couple of months ago
[09:59] <markos_> dunno if it changed
[09:59] <lool> markos_: We plan integrating the CS patches at least on ARM on top of 4.4 https://blueprints.launchpad.net/ubuntu/+spec/arm-m-tool-chain-selection
[09:59] <markos_> i did it the other way
[10:00] <lool> markos_: the other way?
[10:00] <markos_> took the cs source and used a few ubuntu patches on top -incl. graphite- you might find it nice that Eigen showed an extra 0.03 GFLOPS performance 0.89 -> 0.92
[10:01] <neure> what would be nice code editor that runs fine on beagleboard?
[10:01] <neure> for X..
[10:02] <markos_> lool: btw, the difference in a8 vfp vs NEON is huge, this is from a basic Eigen benchmark:
[10:02] <markos_> $ ./bench_gemm.gcc4.4.1cs
[10:02] <markos_> eigen cpu 3.84s 0.0699051 GFLOPS (19.27s)
[10:02] <markos_> eigen real 3.8469s 0.0697796 GFLOPS (19.2648s)
[10:03] <lool> markos_: but that requires custom NEON code in eigen?
[10:03] <zyga> neure, vim
[10:03] <lool> it's not like we can just turn on a toolchain flag which will use NEON, well only partially
[10:04] <neure> sorry im allergic to editors with unix roots :D
[10:04] <markos_> $ ./bench_gemm.gcc4.4.1cs+genesi.neon
[10:04] <markos_> eigen cpu         2.35s         0.913823 GFLOPS         (11.82s)
[10:04] <markos_> eigen real        2.35064s      0.913574 GFLOPS         (11.8205s)
[10:04] <neure> scite should be fine..
[10:04] <markos_> lool: yes, that was my first NEON project :)
[10:04] <neure> does gcc directly support neon?
[10:04] <neure> or does it need some manual coding?
[10:04] <hrw> neure: vim was written under AmigaOS :D
[10:05] <markos_> well... it does do some basic fpu stuff using neon
[10:05] <markos_> but to get top performance and vectorization, you have to do special coding
[10:05] <markos_> A9 has a much better fpu, it's almost as fast as neon
[10:06]  * markos_ has remote access to a prototype quad-core A9 :)
[10:06] <hrw> markos_: i.mx61/63?
[10:07] <hrw> I do not remember which of those is dual and which quad
[10:07]  * gsnedders wonders if we have any A9 hardware here…
[10:08] <wv> Question, I have a Freescale IMX51 board (arm cortex A8) with custom ubuntu. The framebuffer always starts in 1024x768, but I want it to be 1536x384. Where can I change this?
[10:09] <neure> hrw, really?
[10:10] <hrw> neure: yes. first it was Vi IMitation
[10:11] <hrw> neure: "Vim is a text editor released by Bram Moolenaar in 1991 for the Amiga computer. "
[10:11] <neure> "The original vi program was written by Bill Joy in 1976 for an early BSD Unix release"
[10:11] <tmzt> markos_: if you're worried about fpu (I read mmu earlier) why not just use neon?
[10:11] <neure> granted i have no idea how much vim shares with vi
[10:11] <hrw> neure: yes, vi is old timer
[10:12] <markos_> hrw: i think it's a samsung
[10:12] <neure> i was born 1976 :)
[10:12] <tmzt> wv: you might have to do that in the kernel source
[10:12] <hrw> neure: so did I
[10:12] <markos_> tmzt: I am, when I can at least
[10:12] <XorA> sorry
[10:12] <zyga> wv, I think you can do that in the boot loader, just change the kernel command line
[10:12] <XorA> doh wrong window, so lucky that wasnt another random statement :-)
[10:13] <wv> bootloader is redboot, and I don't see any resolution specified in the kernel command line
[10:13] <hrw> wv: run 'fconfig' command
[10:13] <hrw> ah.. no entry...
[10:13] <wv> exec -c "noinitrd console=ttymxc0,115200 console=tty1 root=/dev/mmcblk0p1 rw rootwait wvga"
[10:13] <markos_> hrw: ARMv7 Processor [410fc091] revision 1 (ARMv7), cr=10c53c7f
[10:13] <amitk> wv: AFAIK, the display driver has EDID detection on the imx51
[10:14] <wv> Possibly, but I don't want to use EDID detection
[10:14] <wv> screen is an own made custom fpga screensplitter
[10:14] <hrw> wv: tried "fbset --xres 1536 --yres 384"?
[10:15] <wv> hrw, well, that works after boot, I can output this resolution via fbset
[10:15] <wv> not via this command, but with timings and stuff
[10:15] <wv> but I want it to be correct directly at boottime
[10:16] <amitk> wv: then I guess you'll have to look deeper into the driver for it's default settings
[10:16] <wv> cause second problem is that the x-server gets started at 1536x768 in stead of 384
[10:16] <wv> so I only see the upper half of the screen...
[10:18] <zumbi> win 23
[10:18] <zumbi> err
[10:18] <lool> lose 77
[10:18] <wv> So it's not like I can put a default startup resolution somewhere without modifying some sourcE?
[10:19] <hrw> dpends on x.org driver
[10:20] <amitk> wv: again, look at the modinfo for the driver to see if it takes some parameters (I don't have my babbage board handy atm)
[10:20] <neure> /usr/bin/ld: cannot find -lEGL
[10:21] <neure> where do i get pvr oes and egl stuff?
[10:22] <wv> amitk, can you give me the specific command? I tried modinfo fbdev, but get a ERROR: modinfo: could not open.......;
[10:33] <amitk> wv: I guess the display driver is not even a module, it is compiled in. And from a quick look it doesn't seem to take any parameters
[10:33] <amitk> wv: so you'd have to hack the driver
[10:36] <zumbi> lool: nobody loses :) (I was changing windows :-P)
[10:36] <zumbi> lool: btw, would you know some TI or freescale people wanting to pay money to sponsor debconf food?
[10:37]  * zumbi is fundraising
[10:38] <hrw> zumbi: alt-d is not working as /window 23?
[10:39] <zumbi> hrw: not here alt-d=ä
[10:41] <zumbi> when fundraising, I get more hardware than money for food -- would you like some? :)
[10:43] <hrw> zumbi: ah.. I use RAlt for national chars
[10:49]  * XorA uses ralt for compose
[11:00] <lool> zumbi: It's a bit of a stretch for me to share Canonical customer contact details in the interest of letting you contact them to raise money
[11:02] <lool> zumbi: But I can see various ways in which this could work: a) contacting them during Debconf itself (the ones who come) to sponsor the next debconf b) prepare some information for ARM silicon manufacturers on why debian is great for ARM development and why sponsoring debconf is critical c) let networking happen (I might mention the debconf sponsoring option to the ones I know well, but that's my own personal decision as a DD :-)
[11:02] <lool> zumbi: The other option is that you eat some hardware instead
[11:02] <hrw> ;D
[11:02] <zumbi> tasty :-)
[11:03] <zumbi> thanks :)
[11:03] <hrw> or grab hw to debconf and sell^Wexchange it for food
[11:03] <XorA> sponsored "Will it Digest"
[11:03] <lool> hrw: Reselling hardware which you were offered for development might not be a terribly good move to keep your hardware sponsors happy though
[11:04] <zumbi> lool: as DD if you want to fundraise a little more for food, you can access open budget at http://wiki.debconf.org/wiki/DebConf10/Budget
[11:05] <zumbi> lool: that can be a great idea (hardware reselling booth)
[11:06] <lool> zumbi: Ok, it's good to know the budget bits are there, what might help sponsors make their move is a targetted marketing of why debconf is great for their company/products/communities
[11:07] <lool> zumbi: if you do have a reselling agreement with your partner, that would be good, but otherwise it's quite an ugly business to resell gifts IMHO
[11:07] <lool> I wouldn't be tempted to make further gifts in the future if I saw them being exchanged for money or food
[11:08] <lool> Housing + Food shows how an expensive city like NY hits the debconf budget badly    :-/
[11:08] <zumbi> lool: yes, i already wrote a letter (http://whiteboard.debian.net/sponsors.wb) and thanks for suggestions, I should agree reselling before hand. Exchange hardware for food. :-)
[11:08] <zumbi> lool: btw, will you be there?
[11:09] <lool> zumbi: the list of benefits is not geared towards ARM at all
[11:09] <lool> zumbi: Yes, I'm coming
[11:11] <lool> zumbi: Do you have a list of current sponsors as to not bug the same companies multiple times?
[11:12] <zumbi> lool: yes, but it is kept private
[11:12] <lool> zumbi: Could you mail it to me?
[11:13] <zumbi> lool: i think so
[11:13] <zumbi> one sec
[11:13] <lool> I wouldn't share it obviously
[11:13] <zyga> plars, gomockingbird.com
[11:15] <lool> zyga: Amazing
[11:15] <zyga> lool, just found it on planet.gnome
[11:15] <zyga> I'm redoing my mockups in that, pen and paper sucks
[11:16] <zyga> (and another objective-c -> javascript recompiler app, cool)
[11:18] <zyga> I'm doing ubuntu one sync on my BB
[11:19] <markos_> zumbi: eating hardware... gives a new meaning to "Intel Inside" stickers, lol :)
[11:20] <hrw> markos_: ;DD
[11:21] <zumbi> markos_: well, not Intel, but ARM
[11:22] <zumbi> "Eat the ARM" could be a posible marketing sponsor :)
[11:22] <zumbi> sponsor or phrase or ... i dunno the best word here
[11:26] <tmzt> wv: did you get it through the bootloader?
[11:26] <tmzt> it's possible the bootloader just configures video for itself, not the kernel
[11:27] <tmzt> you probably have to patch the board file or devicetree (if it's used)
[11:27] <tmzt> I don't know this hardware though so I can't be sure
[11:32] <markos_> "this guy ate his ARM", won't sound very nice though...
[11:54] <neure> guys
[11:54] <neure> is there some lighter X environment than ubuntu-netbook?
[11:54] <neure> it seems to be pretty sluggish
[11:56] <ogra> do you have swap ?
[11:57] <ogra> its not that sluggish on a C4 with 512M of swap here
[11:57] <ogra> but indeed there are other desktop envs, try lubuntu-desktop or a plain xfce (not xubuntu-desktop, thats nearly as heavy as ubuntu)
[11:58] <neure> how do i see if i have swap?)
[11:58] <ogra> free
[11:59] <neure> no swap!
[11:59] <ogra> htop is also helpful to see the real ram usage
[11:59] <neure> damn
[11:59] <ogra> (not installed by default)
[12:00] <neure> i have 16 GB sdcard, use% 16..
[12:00] <neure> can i add now somehow?
[12:00] <neure> i can take the sdcard to pc if necessary
[12:00] <ogra> use your desktop pc and gparted
[12:00] <ogra> you should be able to shrink the partition
[12:01] <neure> is gparted x11 program?
[12:01] <neure> my vmware only has shell, no X11
[12:02] <ogra> gparted is X11
[12:02] <neure> :/
[12:03] <ogra> it uses parted and ext2resize in the backend though
[12:03] <ogra> but they are rather complex to use
[12:04] <neure> i need to do apt-get install xfce-4 on my vmware first :D
[12:04] <neure> or something like that
[12:05] <SQlvpapir> you can ssh -X into the box without it having a full X+desktop installed
[12:06] <neure> mm., true
[12:06] <neure> i should install some local X server
[12:06] <neure> probably cygwin?
[12:07] <ogra> just openssh-server and gparted
[12:07] <SQlvpapir> seems like a major workaround. if you can take your desktop down and boot from a usb stick/cd that would be much easier
[12:07] <ogra> then you can do "ssh user@vm -X gparted"
[12:08] <neure> well i first need to install the X server ;)
[12:09] <ogra> you dont need an xserver with openssh
[12:09] <ogra> gparted will pull in what it needs to run
[12:09] <ogra> should only be X libs
[12:10] <ogra> oh, wait, your host is windows ...
[12:10]  * ogra now gets the prob
[12:10] <neure> :)
[12:10] <ogra> just stop using windows ;)
[12:10] <neure> not my choice
[12:10] <ogra> it helps in so many areas :)
[12:15] <neure> running windows, qemu, vmware, windows, qemu in vmware, beagleboard and now adding remote X.. this can get confusing..
[12:15] <neure> double windows :D
[12:20] <amitk> *shudder*
[12:27] <hrw> amigaos -> macos -> windows 3.11 -> zx spectrum
[12:33] <neure> -> ?
[12:33] <hrw> neure: your list of vm reminded me old amiga times
[12:34] <neure> heh
[12:34] <neure> i had c64 instead of spectrum
[12:34] <neure> and i never really used mac
[12:34] <neure> and skipped 3.11
[12:34] <hrw> neure: amigaos as host with mac emulator which was running x86 emul which got zx spectrum
[12:34]  * hrw -> lunch
[12:34] <neure> ah right
[12:34] <neure> :)
[12:35] <neure> you can run that amigaos on winuae.. :)
[12:35] <neure> or some other uae
[13:03] <neure> damn
[13:03] <neure> how the hell do i switch from ubuntu-netbook to some other desktop
[13:03] <neure> ?
[13:04] <ogra> at the login manager select your session
[13:04] <neure> there is no such thing
[13:04] <neure> login manager?
[13:04] <neure> where do i select session?
[13:04] <neure> oh wait
[13:04] <neure> found it
[13:04] <neure> :D
[13:04] <neure> silly me
[13:04] <ogra> fi you log out of netbook you get to the login manager
[13:04] <ogra> :)
[13:05] <neure> i didnt see any session options because i had not chosen user
[13:05] <neure> i was expecting to be able to choose session already before having to select user
[13:11] <neure> mm
[13:11] <neure> lxde <3
[13:11] <ogra> oh, sweet !
[13:11] <ogra> the maverick kernel seems to boot on the XM
[13:11] <neure> sounds good
[13:11] <neure> i wonder when xm is available..
[13:12] <ogra> since last week i think
[13:12] <neure> it can be ordered now?
[13:12] <neure> or you mean it has already been shipped?
[13:43] <neure> how do i add swap with gparted?
[13:44] <neure> hmm i think i got it
[13:52] <hrw> re
[13:55] <asac> ogra: can you document how to set back to uboot env defaults?
[13:55] <asac> whats the way? is that just erasing the mtd2?
[13:56] <ogra> re-flash u-boot
[13:56] <ogra> not sure erasing gets you the defaults back, i never tried
[13:56] <asac> ogra: what do you mean by "reflash uboot"
[13:56] <asac> uboot still has the defaults, its just that it ignores them when there is something different in the uboot env
[13:56] <ogra> re-flash u-boot bin from the u-boot prompt
[13:57] <ogra> right, try to erase the env then
[13:57] <asac> does that write the default env to uboot env?
[13:57] <asac> i am not sure. i just thought that erasing might do the trick too
[13:57] <asac> i will let lool try that
[13:58] <ogra> lol
[13:58] <ogra> coward !
[13:59] <ogra> just dd /dev/zero to mtdblock2 :)
[13:59] <ogra> and reboot
[13:59] <ogra> worst case you have to setenv/saveenv the stuff manually afterwards
[14:03] <lool> geez
[14:03] <lool> you guys are dangerous!
[14:03] <asac> me?
[14:03] <lool> plural!
[14:03] <asac> i feel pretty harmless here
[14:03] <asac> heh
[14:03] <asac> ok
[14:04] <lool> asac: You're discussing with ogra!
[14:04] <lool> jk  ;)
[14:04] <asac> right. i might get infected with more risk ;)
[14:06] <asac> ogra: so in panda world uboot would always use the built in default i guess? how will you work around the problem with partitions on the image production? thought there were problems with cylinders etc.
[14:12] <ogra> *grin*
[14:12] <ogra> asac, using sfdisk
[14:12] <asac> ogra: sfdisk fixes that problem in which way?
[14:13] <ogra> ask NCommander :) he said he has working debian-cd code, i havent seen it yet
[14:13] <asac> feels odd
[14:13] <ogra> parted cant be forced into CHS mode
[14:13] <asac> i mean in best case we can hard code coms cylinder/sector etc. values, but are those true for all sdcards?
[14:13] <ogra> sfdisk can do that fine
[14:13] <asac> what does CHS mode involve?
[14:13] <ogra> putting fixed values in for these
[14:14] <ogra> i dont think it actually matters on mounting at all
[14:14] <ogra> it just matters for MLO
[14:15] <ogra> asac, basically we're re-using the imx51 scripts but use an ext3 partition for the second part. and vfat for the first one
[14:16] <asac> ogra: right, but why would it not be a problem for MLO if the values are wrong
[14:16] <ogra> why would they be wrong ?
[14:16] <ogra> we know the disk size so we can make up proper values here
[14:16] <asac> ogra: are CHS values all the same for all sdcards of all sizes etc.?
[14:16] <ogra> s/disk/image/
[14:16] <ogra> no
[14:16] <asac> so doesnt depend on the hardware?
[14:17] <ogra> they are bound to the card size
[14:17] <asac> but if you produce an image, you dont know what card size the user will choose, do you?
[14:17] <ogra> no
[14:17] <ogra> well, it works is all i can say
[14:17] <ogra> but you wont get anywhere with parted
[14:17] <asac> right
[14:18] <ogra> so sfdisk or fdisk
[14:18] <ogra> or patch parted :)
[14:18] <asac> why sfdisk rather than fdisk? i sfdisk as commonly available?
[14:18] <ogra> yes
[14:18] <ogra> and better scriptable
[14:18] <ogra> actually sfdisk is designed for scripting
[14:19] <ogra> while you need to direct fake input to fdisk if you want to script it
[14:19] <asac> ogra: have oyu tried if it also helps for our imx51 uboot mess?
[14:19] <ogra> nope
[14:19] <ogra> i didnt touch imx51 since months
[14:19] <ogra> and we dont build images for it anymore
[14:19] <ogra> since lucid release
[14:19] <asac> right.  just thought you evalled this switch to sfdisk ;)
[14:20] <ogra> i played with it for omap
[14:20] <asac> i see
[14:20] <ogra> but thats a while ago
[14:20] <ogra> before lucid released
[14:20] <ogra> lets wait with what NCommander comes up ...
[14:21] <ogra> i should get some code this week for review, i can give you the snippets for your livehelper scripts
[14:21] <asac> that would be fantastic
[14:21] <ogra> effectively we're holding back because of alpha1
[14:21] <asac> can we have a config file with the partition layout?
[14:21] <ogra> we dont want to disturb the milestone with code commits atm
[14:21] <asac> rather than a loose command script?
[14:22] <ogra> i think its written like the other debian-cd scripts so you will likely have vars at the top
[14:22] <asac> ogra: are a1 images for omap going to happen?
[14:22] <ogra> you can indeed put these vars into a config file you source
[14:22] <ogra> asac, nope
[14:22] <asac> ;)
[14:22] <asac> ogra: what is outdated?
[14:22] <ogra> livecd-rootfs is ready but i'm scared to merge it in the middle of a milestone freeze
[14:23] <asac> right
[14:23] <ogra> debian-cd misses the publishing code according to NCommander
[14:23] <ogra> i have him access to a branch so he can work on it but i havent seen code yet
[14:23] <asac> wow ftbfs growed again ;)
[14:23] <ogra> according to him the images are built and bootable
[14:23] <ogra> yeah, QT
[14:23] <asac> hmm
[14:24] <ogra> ftbfs is second prio atm
[14:24] <asac> ogra: the qt fix should be changing the typedef for long to long rather than int
[14:24] <ogra> we're working towards having daily builds
[14:24] <asac> and drop all ncommander patches and rebuild the full qt stack
[14:24] <asac> ogra: daily builds? we already have daily builds, dont we?
[14:24] <ogra> well, i was told there is another timout issue too
[14:24] <ogra> we dont have any arm images atm
[14:24] <asac> ogra: in anycase, the typedef migration hsould be done asap
[14:25] <ogra> feel free to do it or wait until the images build :)
[14:25] <asac> ogra: err. we had daily images last cycle (unless they failed)
[14:25] <ogra> right
[14:25] <ogra> but we're changing the build system completely
[14:25] <asac> so why are you working on getting daily images?
[14:26] <ogra> because we are not able to build them right yet
[14:26] <ogra> building the old ones wastest space on cdimage and requires manual clanup work someone has to do later
[14:26] <ogra> so we dont build the old ones and the code for the new ones is still in the works
[14:27] <asac> ogra: so what does this "make daily builds happen" involve?
[14:27] <ogra> antimony/cdimage is short on diskspace
[14:27] <asac> why dont you work with us on using the same infrastructure?
[14:27] <ogra> because you dont work in the distro infarstructure
[14:27] <ogra> and 60% of our work is done
[14:28] <asac> so you are saying you just ensure that there is more disk space left?
[14:28] <ogra> the ext3 image buiold code is ready and working, just not merged to the livefs builder yet
[14:28] <ogra> no
[14:28] <asac> i mean if you move your stuff to a separate host, you could also embrace our system as a "distro" infrastructure part
[14:28] <ogra> oh, yes, on antimony
[14:28] <ogra> then we would have to maintain a separate machine
[14:29] <ogra> we want to have our  distro builds in the distro infrastructure
[14:29] <ogra> there is no way around it
[14:30] <ogra> since there are plenty of people maintining that it would be a massive waste (and not doable for our team) to have to maintain a complete additional machine and infrastructure
[14:31] <ogra> also we dont want to duplicate code
[14:31] <asac> ogra: right thats why i suggested to share the infrastructure for live-helper
[14:31] <ogra> debian-cd and livecd-rootfs are there and well maintained
[14:31] <asac> but i see that you guys are not yet ready mentally for looking for different stuff ;)
[14:31] <markos_> ogra: rootstock/qemu gave me a fatal error: "qemu: fatal: cp15 insn ee1d6f70"
[14:31] <asac> so move ahead ;)
[14:31] <ogra> not with the current time schedule
[14:32] <markos_> while building a ubuntu-minimal image with hardfp debs
[14:32] <ogra> asac, dont forget we only have a about 6 weeks until release
[14:32] <asac> ogra: sure. just saying you shouldnt invest too much work there. if you put real man cycles into it now, we should rather go and share our efforts
[14:32] <markos_> that's on lucid x86_64 on a VM
[14:33] <asac> ogra: what i dont get is that we had more images last cycle, and now the diskspace is not enough to have dailies for a single image?
[14:33] <ogra> markos_, probably the VM kernel
[14:33] <ogra> asac, preinstalled images require a lot more space
[14:33] <XorA> scripts/kconfig/kxgettext.c: In function ‘message__add’:
[14:33] <XorA> scripts/kconfig/kxgettext.c:148: internal compiler error: Segmentation fault
[14:33] <ogra> the raw image is 1.4G and we can only compress it at the end of the build process
[14:33] <XorA> arse
[14:33] <markos_> ogra: ok, i'll just fix the antive build anyway
[14:35] <asac> ogra: oh true. you could lzma them though
[14:35] <XorA> ogra: built a kernel natively on omap4?
[14:35] <ogra> asac, we'll bzip them but still they are raw first
[14:35] <asac> but squashfs is also raw first, isnt it?
[14:35] <asac> nevermind.
[14:36] <ogra> yeah, squash lives on the livefs builder
[14:36] <ogra> and comes over in compressed format
[14:36] <ogra> we could compress on the livefs builder but that takes hours on a imx51 CPU
[14:37] <ogra> so we have to live with uncompressed and then compress on antimony
[14:37] <ogra> the resulting image is only 4-500M though :)
[14:37] <ogra> XorA, yes, several times
[14:38] <XorA> ogra: seen anything like my error above?
[14:38] <ogra> XorA, what kernel do you run on the machine ?
[14:38] <XorA> ogra: L24.6
[14:38] <ogra> and what HW is that ? a zoom ?
[14:38] <ogra> i have seen random segfaults, yes
[14:38] <ogra> err s/&zoom/blaze/
[14:39] <XorA> ogra: this is a 4430 SDP
[14:39] <ogra> XorA, usually it survives uImage creation but fails some time during modules creation
[14:39] <XorA> its not random happens every time
[14:39] <ogra> or if i build modules first it survives the modules but happens on uImage creation
[14:39] <ogra> i also had builds that survived completely
[14:40] <ogra> but there are known kernel issues on omap4
[14:40] <ogra> oen is definately exposed if you use git clone with a recent git version
[14:40] <ogra> try that :)
[14:40] <ogra> (but be prepared for reboot)
[14:41] <ogra> i know its known at TI
[14:43] <lool> markos_: this seems bad
[14:43] <lool> markos_: If you like, you could try the qemu-maemo/meego packages, they have a handful more ARM patches
[14:44] <lool> markos_: https://launchpad.net/~lool/+archive/ports-dev/+packages
[14:44] <ogra> lool, do you plan to bring them to the archive at some point ?
[14:44] <markos_> lool: well, only for x86 rootstock, I'm working on a native rootstock right now
[14:44] <lool> ogra: No, I'd rather avoid adding a fork to the archive; some of the patches were submitted upstream now though
[14:44] <ogra> ah, great
[14:45] <ogra> though the question is which upstream then :)
[14:45] <ogra> i.e. will they show up in the kvm port
[14:45] <lool> Ultimately they will, but yeah, it will take longer
[14:48] <asac> ogra: so compressing to squash is considerably faster than compressing to gzip/bzip/lzma?
[14:49] <asac> or you also want to improve image build time?
[14:49] <ogra> on arm HW, yes
[14:49] <ogra> no, but i want to have a reasonable build time
[14:49] <asac> cant we just ship the image .squashfs compressed then ;)?
[14:49] <ogra> rolling the ext2 takes about 40min
[14:49] <asac> j.k.
[14:49] <ogra> no
[14:50] <ogra> did you read the spec ?
[14:50] <ogra> we're growing the existing partition to the size of the SD on first boot
[14:50] <XorA> ogra: yeah I noticed the git clone failure.
[14:50] <ogra> cant do that with a readonly squashfs ...
[14:50] <ogra> and it would force a union mount
[14:57] <markos_> lool: better, a few errors, but i think i'll make it work
[14:59] <markos_> ogra: it gives me chroot: cannot run command debootstrap/debootstrap: no such file or directory
[15:01] <ogra> markos_, you installed the lucid package ?
[15:01] <markos_> yes, but trying to build karmic image
[15:02] <ogra> that shouldnt matter
[15:02] <ogra> did it pull in qemu-kvm-extras-static ?
[15:03] <ogra> seems your binfmt handler for armel chroots doesnt work
[15:03] <markos_> that's a pristine lucid install :P
[15:03] <ogra> dpkg -l|grep  qemu-kvm-extras-static
[15:03] <ogra> is it installed ?
[15:04] <markos_> yes, 0.12.3+noroms-0ubuntu9
[15:04] <ogra> try: sudo service binfmt-support restart
[15:04] <ogra> and then try again
[15:04] <ogra> worst case try a reboot
[15:05] <markos_> ok, here is the problem:
[15:05] <cwillu_at_work> does plymouth work under dss?
[15:05] <markos_> with default qemu-arm-static I have the fatal error in qemu I mentioned before
[15:06] <ogra> cwillu_at_work, on my C4 it does
[15:06] <cwillu_at_work> k, so I just don't know how to work it then :)
[15:06] <markos_> ogra: with qemu-maemo, there is no static version, so I think it may possibly break when trying to run it inside a chroot -missing libs?
[15:06] <ogra> cwillu_at_work, you have quiet and splash on your cmdline ?
[15:06] <cwillu_at_work> ogra, I'm actually trying to bring it up by hand from a serial console
[15:07] <ogra> markos_, no, the binfmt handler uses the qemu-arm-static binary
[15:07] <ogra> markos_, so even if you use qemu-maemo that will only affect VMs
[15:07] <cwillu_at_work> markos_, which fatal error?
[15:08] <markos_> ok, i'll have to copy paste this to some pastebin, moment
[15:08] <ogra> ok
[15:08] <ogra> cwillu_at_work,  fatal error: "qemu: fatal: cp15 insn ee1d6f70"
[15:08] <cwillu_at_work> partway through the install?
[15:08] <ogra> cwillu_at_work, though he recompiled the world with hardfp
[15:09] <cwillu_at_work> ah, okay
[15:09] <ogra> the vm kernel is surely not compiled like that
[15:09] <ogra> so that might cause this issue ... or something in qemu itself
[15:10] <markos_> http://paste.debian.net/75826/
[15:11] <cwillu_at_work> :/
[15:11] <cwillu_at_work> plymouthd seems to ignore it's --tty arg;  it looks like it's trying to open the serial terminal for splash even though I'm passing --tty=/dev/tty1
[15:11] <ogra> markos_, yeah, thats in the VM if i'm not totally wrong
[15:12] <markos_> ogra: but the kernel doesn't use fpu at all, it should be totally agnostic whether I use softfp or hardfp or whatever
[15:12] <ogra> markos_, what you can try (but will slow down rootstock) is to remove the static package
[15:12] <markos_> i don't mind :)
[15:12]  * ogra isnt sure he made qemu-arm-static a recommends
[15:12] <ogra> gah, i didnt
[15:13] <markos_> retrying without it
[15:13] <ogra> so you might have to re-rooll the package without that dep
[15:13] <ogra> rootstock will then use the VM for everything
[15:13] <ogra> so should use qemu-maemo all over the place
[15:14] <markos_> seems to do exactly that
[15:14] <ogra> phew, at least that code works :)
[15:14] <markos_> "Switching to VM for 2nd stage processing"
[15:14] <markos_> Installing core packages...
[15:14] <markos_> fingers crossed :)
[15:14] <ogra> :)
[15:14]  * ogra just got icecream ...
[15:14] <ogra> -> afk for a bit
[15:47] <cwillu_at_work> ogra, heh;  apparently using having a serial console available on boot breaks it
[15:47] <ogra_cmpc> oh, indeed, i forgot about that
[15:47] <ogra_cmpc> i even filed thwe bug in LP for it
[15:49] <cwillu_at_work> you know offhand if it breaks if the serial console is display only?
[15:49] <cwillu_at_work> (i.e., the first of two console= args)
[15:50] <ogra_cmpc> iirc it breaks with any console= setting
[15:50] <cwillu_at_work> I just had it work with console=tty1
[15:50] <ogra_cmpc> hmm, then this part was fixed
[15:56] <cwillu_at_work> order doesn't matter on two devices
[15:56] <cwillu_at_work> just doesn't work
[15:56] <cwillu_at_work> k
[15:56] <lool> hrw: BTW I updated the cross-compilers spec to include doko's feedback, check the diff for the detailed changes, but the highlights are: fortan expected as well (to match upstream default set of languages), cross-toolchain rules should allow using embedded sources, should not go above dh 5 for now
[15:57] <markos_> lool: speaking of compilers, how do you bootstrap java (gcj/openjdk)?
[15:59] <ogra_cmpc> we have a tool for that ... it's called doko ;)
[15:59] <markos_> haha
[16:03] <lool> markos_: Good Q, I don't know
[16:08] <hrw> lool: I checked them when you added
[16:15] <markos_> lool: only java and mono are left from the big/important/lots of dependencies packages so far
[16:15] <markos_> reg. mono, I suspect the CS compiler braking the build somewhere, but I'm looking at it for days
[16:15] <lool> apw: Heya, did you see my ubuntu-maverick-meta patch, complementing the ubuntu-maverick linux-tools armel support?
[16:16] <lool> markos_: Ok good to know
[16:16]  * ogra saw it on the ML
[16:38] <cwillu_at_work> lucid's x still grabs the screen eh?
[16:38] <cwillu_at_work> ... from plymouth, on omap
[17:25] <cwillu_at_work> did we drop xorg's omapfb?
[17:25] <ogra> nope
[17:26] <cwillu_at_work> rename it?
[17:26] <cwillu_at_work> merge it with something else?
[17:26] <cwillu_at_work> :D
[17:26] <ogra> it has the same name debian gave the package
[17:27] <ogra> https://edge.launchpad.net/ubuntu/+source/xf86-video-omapfb
[17:27] <ogra> xserver-xorg-video-omap3 or xserver-xorg-video-omapfb
[17:28] <ogra> make your pick (NEON or not)
[17:28] <cwillu_at_work> sorry, distracted
[17:29] <cwillu_at_work> and less distracted now
[17:29] <cwillu_at_work> I don't see xserve-xorg-video-omap* anymore
[17:29] <cwillu_at_work> nothing that starts with o
[17:30] <ogra> cwillu_at_work, where do you look ?  we only build it for armel
[17:30] <cwillu_at_work> ogra, on a beagle
[17:30] <cwillu_at_work> I do see a bunch of xserver-corg-video-{1.0,1.9,2,4,5,6} though
[17:30] <ogra> its in universe, is that enabled ?
[17:30] <cwillu_at_work> yep
[17:31] <ogra> lucid ?
[17:31] <cwillu_at_work> yep
[17:31] <ogra> weird
[17:31] <ogra> i use it here
[17:31] <cwillu_at_work> I used it in karmic
[17:31]  * cwillu_at_work apt-get updates unnecessarily
[17:32] <ogra> as you can see on the LP page above it exists :)
[17:32] <cwillu_at_work> liar
[17:32] <ogra> heh
[17:32] <cwillu_at_work> and as long as I have your attention, novtswitch or similar doesn't seem to work;  is that just me?
[17:32] <cwillu_at_work> trying to get that smooth splash experience working :)
[17:33] <cwillu_at_work> geez
[17:33] <ogra> hmm, not sure if novtswitch is recognized by plymouth
[17:33] <cwillu_at_work> no, by xorg
[17:33] <ogra> it might switch forcefully
[17:33] <ogra> (before xorg comes up)
[17:33] <cwillu_at_work> xorg switches forcefully, regardless of the switch
[17:34] <cwillu_at_work> I'm running plymouth, and I want plymouth to stay on the screen until an app is loaded in xorg
[17:34] <ogra> might be that the new xorg doesnt anymore
[17:34] <cwillu_at_work> but xorg switches vt's (which I can deal with) and clears the screen (which I can't)
[17:34] <ogra> man xorg doesnt have it
[17:34] <cwillu_at_work> Xorg --help does
[17:35] <ogra> best ask in #ubuntu-x
[17:35] <ogra> they might know if thats just a missed leftovert in the documentation
[17:36] <ogra> everything relies on KMS nowadays so it might actually be that the option is gone
[17:36] <cwillu_at_work> ahhhh, and dss isn't a kms driver
[17:40] <cwillu_at_work> how does plymouth-x11 work?
[17:41] <ogra> no idea :)
[17:41] <ogra> i know TI works on adding KMS support for the future
[17:44] <jussi> right, Im going to ask this one final time, because I know you all hate it when I ask, but what arch is the imx51?
[17:45] <ogra> jussi, ARM :)
[17:45] <jussi> ogra: so arm and not armel, right ?? :D
[17:45] <ogra> jussi, cortex-a8 ARMv7
[17:45] <sebjan> I generated a kernel source package (debuild). Now I'd like to generate the kernel image and headers packages from it, in native build (ARM). What command shall I run / where to find this info?
[17:45] <ogra> armel just means arm with little endian
[17:46] <ogra> all arm HW we support or ever supported is little endian
[18:01] <Martyn> After reading much of what was posted on the GCC list, I'm confused as to why GCC wants to adopt C++ into GCC (vs g++) ... When it comes down to it, what's the reason for the upcoming proposed change?
[18:01] <cwillu_at_work> Martyn, aren't they just talking about allowing the use of c++ in the implementation of gcc?
[18:02] <Martyn> I think so .. but I really haven't understood why.
[18:02] <rsavoye> it's cause for some things C++ works better. ie, look at the new Gold linker
[18:04] <sebjan> amitk: ping
[18:05] <amitk> sebjan: pong
[18:05] <sebjan> amitk: I generated a kernel source package (debuild).
[18:05] <sebjan> amitk: Now I'd like to generate the kernel image and headers packages from it, in native build (ARM).
[18:06] <sebjan> amitk: I have seen some guidelines on https://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter for doing so on qemu
[18:06] <amitk> sebjan: yes, using sbuild
[18:06] <sebjan> amitk: but had issues (probably with proxy settings...), and would anyway like to do on natively on my ARM board
[18:07] <cwillu_at_work> Martyn, that means it's not vs g++ at all
[18:07] <cwillu_at_work> ie, they're not talking about compiling c++ via gcc
[18:07] <amitk> sebjan: build the kernel on the board? ok. What is the problem?
[18:08] <sebjan> amitk: build the image and headers packages from my source package on the board
[18:08] <sebjan> amitk: what would be the sbuild command line then?
[18:09] <amitk> sebjan: the debuild line should work, you don't need an sbuild then
[18:09] <sebjan> amitk: I am also able to generate kernel image and header .deb using debian/rules, but I suppose this is not the best way to do it to emulate what would happend after uploading my source package on a ppa, right?
[18:10] <amitk> sebjan: ohh, I see, the wiki page only uses debuild to make a source package, not to compile the kernel
[18:10] <sebjan> amitk: yes, right :)
[18:11] <ogra> debuild -b
[18:11] <amitk> sebjan: debuild -b
[18:11] <ogra> instead of -S
[18:11] <amitk> aah, ogra beats me to the punchline as always :-p
[18:11] <ogra> :)
[18:12] <sebjan> ok, so debuild -b will generate the image and headers packages? (all the packages specified in my debian folder I guess)
[18:12] <ogra> all binary packages
[18:13] <amitk> sebjan: it will do what happens on a buildd
[18:14] <amitk> sebjan: so prepare to wait a few hours
[18:14] <sebjan> amitk: ok, I'll try this tonight then :)
[18:15] <sebjan> amitk: ogra: thanks!
[18:15] <amitk> sebjan: give the command with 'time' in front of it. Would be interesting to see how long it takes on your new boards :)
[18:16] <sebjan> amitk: yep, I'll do that :)
[18:17] <ogra> what kind of board is that ? omap4 ?
[18:17] <dmart> Does anyone know a way to snapshot a load of data from /proc?
[18:17] <ogra> if so there was a trick to make it use -j2
[18:17]  * ogra cant remember it though
[18:17] <dmart> tar and cpio fail, because proc files read as zero-sized when you stat them
[18:19] <ogra> amitk, do you rememebr the switch to make debuild use multiple cores ?
[18:20] <amitk> ogra: debuild -j2 ?
[18:21] <ogra> heh, yeah, i guess thats it
[18:21] <ogra> -j2 makes a significant difference on omap4
[18:23] <amitk> dmart: find /proc -maxdepth 1 -type f | xargs cat | less
[18:23] <jcrigby> ndec:ogra sent me to you.  I saw some omap4/cortexa9 patches from aneesh@ti.com on the u-boot mailing list last week
[18:23] <amitk> dmart: this gets your the output, you could add some echos to add the filename above it?
[18:24] <dmart> amitk: that could work... I'll play around with it.  Thanks
[18:44] <cwillu_at_work> hmm
[18:45] <cwillu_at_work> seems like a trivial change to re-enable novtswitch
[20:23] <markos_> ogra: is there any way to enable/force unauthenticated repos in rootstock?
[20:27] <markos_> I get "E: There are problems and -y was used without --force-yes"
[20:29] <markos_> nm, it was a different error
[20:33] <markos_> apparently it failed reading my non-english /etc/default/console-setup
[20:33] <markos_> anyway restarting