| === pizthewiz_ is now known as pizthewiz | ||
| janimo` | infinity, one way of solving the ghc issue is by not touching ghc at all, instead making llvm default to float-abi=hard on armhf. I don't know what the downside of that is, besides being Ubuntu specific change | 06:29 |
|---|---|---|
| janimo` | llvm's llc being a cross-compiler always - native being a particular subset - maybe it is good to always have explicit flags for almost everythinh | 06:30 |
| micahg | janimo`: you can ask Sylvestre from Debian | 06:54 |
| janimo` | micahg, ok thanks | 06:55 |
| micahg | janimo`: also, I have another Chromium upload today, so let's hope armhf builds this time | 06:55 |
| janimo` | micahg, oh nice, let's hope it does :) | 06:55 |
| suihkulokki | This would be nice to get to precise: http://sourceware.org/ml/libc-ports/2012-02/msg00079.html | 08:22 |
| micahg | https://launchpad.net/ubuntu/+source/chromium-browser/17.0.963.66~r124982-0ubuntu1/+build/3265949 will be the entertainment for this morning :) | 08:41 |
| === zyga-xchat is now known as zyga | ||
| sveinse | ogra_, infinity : What /is/ the expected behavior on Ubuntu (in general) if the RTC clock has been reset (due to empty battery etc.)? | 09:25 |
| ogra_ | sveinse, i belive there are various userspace apps that will have issues once you drop back to the epoch | 09:40 |
| ogra_ | but i cant tell for sure ... | 09:42 |
| ogra_ | what i know is that for example gdm has probs with autologin once the epoch kicks in, but since we switched to lightdm thats not an issue anymore for us (and i doubt anyone will look into it with much motivation, now that gdm is in universe) | 09:43 |
| sveinse | ogra_, I mean, is it expected that the system should start up normally? | 09:43 |
| sveinse | E.g. since there was a need for fixrtc in the first place, I mean | 09:44 |
| ogra_ | no idea, really, i havent tried it .... and on i.e. the pandaboatd the "epoch" was picked by TI and defaults to 1990 ... so we wouldnt have these issues there at all | 09:44 |
| ogra_ | fixrtc stems from a time where there was a bug in fsck | 09:44 |
| ogra_ | that bug was fixed post lucid, but we kept fixrtc for the potentially broken userspace issues | 09:45 |
| ogra_ | its just still around for historical reasons | 09:45 |
| ogra_ | the initial bug that caused its existance is long gone | 09:45 |
| sveinse | yeah, so my mountall (perhaps fsck) lockup is worth investigating -- even on natty | 09:45 |
| ogra_ | right | 09:46 |
| ogra_ | though i doubt anyone will invest time into natty unlerss someone sends a patch that can be easily included | 09:46 |
| ogra_ | simply because its EOL so soon | 09:46 |
| sveinse | yes, because the reason I'm bringing this up, is that we have been running with protoypes for over a year now. And we've never seen this lockup before. I can't honestly belive that all of these units have had valid rtc contents. | 09:48 |
| sveinse | So it could be a fsck-kernel regression of sorts. | 09:48 |
| sveinse | I'll take a look at it since we have to fix it anyways. I'll keep you in the loop | 09:48 |
| sveinse | While I'm at it: Our hw is headless, we just have a serial console. Yet I see mountall connecting to plymouth. How can I direct the output (like from fsck) from plymouth out on /dev/ttyO2 ? | 09:50 |
| ogra_ | you should be able to use the text theme, it should just display on the default console you set on the kernel cmdline | 09:58 |
| sveinse | thanks | 09:58 |
| ogra_ | if that doesnt work, ask the guys in #ubuntu-server, they definitely have experience with headless servers that run fsck on serial | 10:00 |
| === dmart_ is now known as dmart | ||
| === zyga is now known as zyga-afk | ||
| janimo` | Laney, for ghc I assume you want a clean and properly upstreamable patch for armhf ftbfs not just any fix until upstream fixes it? | 12:33 |
| === zyga-afk is now known as zyga | ||
| Laney | janimo`: I don't know how long the upstreamable patch would take. I'm quite keen to get it fixed in the distro ASAP so if we need to do it in two stages then that's OK with me. | 12:54 |
| Laney | I tried some stuff including using cpp on the Debian porterbox but nothing has stuck yet | 12:54 |
| Laney | and the builds take so long which makes it quite frustrating | 12:55 |
| janimo` | Laney, worst case is put a sed in debian/rules, guarded by ifdef armhf :) | 12:55 |
| Laney | yeah | 12:55 |
| janimo` | to append -float-abi=hard in that one .hs file. | 12:55 |
| janimo` | evil but matches your ASAP requierement | 12:55 |
| janimo` | I looked at what it takes to make it proper(er) | 12:55 |
| janimo` | and it needs changes across many haskell files | 12:56 |
| Laney | I don't mind that. Or you could have a .patch that is applied and unapplied conditionally | 12:56 |
| janimo` | Laney, wait I keep forgetting to ask this. Is there support for debian/patches/foobar.patch.armhf ? | 12:56 |
| janimo` | if so, much cleaner than running sed :) | 12:57 |
| janimo` | apply a single line patch if armhf | 12:57 |
| Laney | no(t that I know of) | 12:57 |
| janimo` | ah, shame | 12:57 |
| Laney | it would be ifeq(armhf,$(DEB_HOST_ARCH))\n\tpatch ... | 12:57 |
| janimo` | and that patch would not be listed in series? | 12:57 |
| Laney | indeed, managed separately | 12:57 |
| Laney | it's not that nice but it makes the separation cleaner | 12:58 |
| Laney | don't know if it's worth it | 12:58 |
| janimo` | not vastly cleaner than a search and replace then | 12:58 |
| janimo` | true. A bit more declarative | 12:58 |
| Laney | anyway this issue blocks the large transition so the sooner it is resolved the better imho | 12:58 |
| janimo` | Laney, the sooner is calling sed then. Or I can try coming up with a patch - which if not what upstream would make it is still a patch. | 12:59 |
| janimo` | sed would unblock the transition | 12:59 |
| janimo` | and we could work on an upstreamable fix in the meantime | 12:59 |
| Laney | OK, go for that then | 12:59 |
| janimo` | Should I try this an dupload in Ubuntu? | 13:00 |
| Laney | yeah, if you're confident it will work | 13:00 |
| Laney | i.e. if you don't feel the need to test build on the porterbox | 13:00 |
| janimo` | Laney, I test on my panda first just to be sure | 13:01 |
| Laney | ok | 13:01 |
| janimo` | Laney, I see sed is no stranger to debian/rules in ghc, called a few times already | 13:08 |
| infinity | janimo`: Just make sure whatever you do is also undone in the clean target, on the off chance that someone builds the source on an armhf box. | 13:09 |
| janimo` | infinity, good point wrt undoing. Not sure I understand what happens though if it is built on an armhf box? | 14:00 |
| infinity | janimo`: If you build the source (ie: debuild -S) on an armhf box, the patched bits would stay patched and never get unpatched on, say, armel. | 14:07 |
| infinity | janimo`: Hence why clean needs to undo whatever you do. | 14:07 |
| janimo` | infinity, if I debuild -S on x86 before uploading is this still an issue in this particular case? | 14:08 |
| infinity | janimo`: Not if you never touched it on armhf in that source tree. | 14:08 |
| infinity | janimo`: (ie: if the sed/patch never ran, then building the source on x86 would work around debian/rules being incorrect) | 14:09 |
| infinity | janimo`: Still, clean should always return you to a pristine source, that's kinda the point. ;) | 14:09 |
| infinity | (Not that there aren't plenty of broken source packages for which this isn't true) | 14:09 |
| janimo` | infinity, ok. I know clean should clean up, just forgot when I explciitly need to do something about it | 14:10 |
| infinity | janimo`: Always. :P | 14:10 |
| janimo` | if I upload this change - which is not yet certain, depending on result on panda - it hopefully is a very shortlived hack, just to get other package sunblocked | 14:11 |
| infinity | janimo`: But I haven't looked at ghc's debian/rules, it could be a lost cause anyway. If it's seding the source elsewhere, odds are the clean target's already wrong. | 14:11 |
| infinity | (Unless clean very carefully reverses every single one of those) | 14:11 |
| janimo` | infinity, it is sedding ony in debian/tmp - that is less evil I guess. various install time changes in .desktop files and such from what I saw | 14:11 |
| infinity | Ahh, yeah, that's fine. | 14:12 |
| infinity | Since clean will wipe out debian/tmp anyway. | 14:12 |
| infinity | Really, the best way to go, if it's a quiltish package, is just to have a patch, but don't have it in the series. | 14:12 |
| infinity | And just patch manually iff armhf, and unconditionally (ignoring errors) unpatch in clean. | 14:12 |
| janimo` | nah, luckily sedding instead of patching is not a widespread habit. I am not advocating it either, but the cost of coming up in short time with a patch spanning multiple haskell fiels and horrid M4 code seems a bit higher now | 14:12 |
| infinity | Heh. | 14:13 |
| janimo` | it is 3.0 so I think quiltish | 14:13 |
| infinity | Fair enough. ;) | 14:13 |
| janimo` | only patching via vi is nastier (chort tied to testicles, etc) | 14:13 |
| janimo` | chord | 14:13 |
| infinity | No one's stopping you from rgrep | xargs sed && dpkg-source --commit && remove from series. | 14:14 |
| infinity | Ish. | 14:14 |
| infinity | But anyhow, as you note, it's a short-term hack, doesn't matter deeply. | 14:14 |
| infinity | And I guess the real fix needs ghc to take configure flags for float-abi, so it's not just always doing the one (wrong or right, depending) thing for armv7? | 14:15 |
| infinity | fpc needs similar pain applied. | 14:16 |
| janimo` | right, the real fix would be - AFAICT - adding code to aclocal.m4 to pass a new flag to the build depending on _VFP_ABI (whatever is's called) | 14:16 |
| janimo` | and that flag being added in the haskell sources and one of the ARM Arch parameters | 14:17 |
| janimo` | or hmm, maybe a configure flag would be indeed easier than changing m4 - did not look at what exaclty that build system does | 14:17 |
| janimo` | but still unless the patch to haskell is a hack and piggybacks floatabi flag of AR ISA extensions (such as NEON, VFP) where it does not logically belong | 14:18 |
| janimo` | it means quite more than an oneliner in .hs files | 14:18 |
| janimo` | every pattern match on ArchARM changed to carry one more param, even if unused in all cases | 14:19 |
| janimo` | so I am not very encouraged to come up with a patch knowing almost for certain it should be rethought/rewritten to match upstream's taste and future plans in this area | 14:20 |
| infinity | janimo`: Assuming upstream cares at all about the distinction, yeah. | 14:23 |
| infinity | janimo`: Many upstream don't seem to. | 14:24 |
| janimo` | they have flags for NEON, VFP, VFPD16, preV7 ARM, preV6 ARM. I assume they care :) | 14:24 |
| janimo` | which reminds me, I should ping llvm debian maintainer. All this hassle would be avoided if llc just defaulted to hardfloat if called on a hardfloat system. | 14:25 |
| janimo` | at the cost of tripping up if crossbuilt from armel sometimes | 14:25 |
| janimo` | I wonder if llvm should have different defaults as gcc does in our default installs | 14:26 |
| infinity | Probably, but I'm not terribly familiar with how llvm internals work. | 14:40 |
| infinity | Individual packages clearly shouldn't have to know or care about what flags they're building with, though. The toolchain should default to something sane. | 14:41 |
| janimo` | micahg, at least chromium did not fail with V8/HARD flag missing this time. gles/egl missing is at least known territory | 15:56 |
| ogra_ | did it fail again ? | 15:59 |
| ogra_ | bah | 15:59 |
| kalikiana | would it make sense to assume libgles2-mesa-dev [armel] is why it fails? | 16:00 |
| kalikiana | ie. use armhf | 16:00 |
| kalikiana | I'm not so versed on multi-arch, though | 16:00 |
| janimo` | kalikiana, that is exactly why it probably fails indeed | 16:01 |
| janimo` | I know I saw that before, not sure why I did not correct it then | 16:01 |
| === zyga is now known as zyga-food | ||
| === chrisccoulson_ is now known as chrisccoulson | ||
| orated | Hello! | 17:59 |
| orated | Can anyone suggest a good board/general resources to start on ARM? | 18:04 |
| GrueMaster | Several, depending on budget and what you want to accomplish. beagleboard.org has decent boards that are supported by Ubuntu, as does pandaboard.org. Also, Freescale has a similar platform called the Quickstart. | 18:06 |
| GrueMaster | All three are fully supported by Ubuntu with images. Any armv7 platform will run the Ubuntu software load as well, provided you can find a kernel. | 18:08 |
| orated | I went through the freescale, what's the difference between all the above you said and reaspberry pi? | 18:13 |
| GrueMaster | Main difference: We don't support the Raspberry PI due to architecture differences (it is not armv7 and would require a top-down rebuild of our arm pool - ~15k packages). | 18:14 |
| === zyga-food is now known as zyga | ||
| GrueMaster | We just don't currently have the resources. | 18:15 |
| MRSL | Hello. I'm new to Linux and trying to change the mux values in mux.c and mux44xx.c so the expansion ports J3 and J6 on the pandaboard will read GPIO rather than the standard setup. I haven't been able to figure out how to do this. I was in the pandaboard forum and they suggested I come over here for instructions. They said to start by getting a working build environment, but I don't actually know how to do that, as my Linux experien | 18:17 |
| orated | GrueMaster: Well, thanks for the input. I'll find about the other two manufacturer you said | 18:17 |
| GrueMaster | beagleboard.org has three different platforms (and three different price points). Panda is overall the best for most desktop usages (dual core, video acceleration (closed source), BT, wifi & ethernet). | 18:19 |
| GrueMaster | Freescale has native SATA. | 18:19 |
| GrueMaster | So it really depends on what you want to use it for. | 18:20 |
| === orated_ is now known as orated | ||
| MRSL | can anyone help me, or point me to where I can get help? | 18:25 |
| GrueMaster | It depends on the type of help. irc is a really big place. | 18:25 |
| MRSL | help with changing the the mux setup on linux on the pandaboard. | 18:28 |
| MRSL | the pandaboard irc sent me over here | 18:29 |
| * GrueMaster goes to look at the pandaboard backscroll. | 18:29 | |
| GrueMaster | MRSL: Best info I can give you is this: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel | 18:33 |
| GrueMaster | As to gpio manipulation, that is #pandaboard. | 18:33 |
| MRSL | okay, thanks | 18:34 |
| GrueMaster | You can use your panda to recompile the kernel, but it can take a few hours. Cross-compiling on my Core2Quad takes ~20 minutes. | 18:34 |
| MRSL | how do you cross-compile? | 18:35 |
| GrueMaster | Sorry I can't help much more than that. For Ubuntu kernel specific questions, you might get more help on #ubuntu-kernel. We can help with the arm environment here. I know it is a PITA to bounce around IRC like this. | 18:36 |
| GrueMaster | The wiki pointer I gave you has specific instructions for the omap4 kernel cross-compile near the bottom. | 18:36 |
| MRSL | alright thanks, I'll head there. And, its better than before, when I was absolutely stuck | 18:37 |
| GrueMaster | What are you running on your desktop? | 18:37 |
| MRSL | Currently the board is running on its own. Ubuntu 10.4 runs on the desktop that I used to originally boot the board | 18:40 |
| GrueMaster | One way to get a working cross-compile environment on your desktop is to download http://cdimage.ubuntu.com/ubuntu-core/daily/current/precise-core-i386.tar.gz and use it as a chroot. That's what I am doing (and I also have Lucid on my desktop). | 18:42 |
| MRSL | Okay. On a side note, using the command from the wiki page to get the source gives an error saying that 'You muust put some 'source' URIs in your sources.list'. Do you know what that means? | 18:45 |
| GrueMaster | Yes. You will need to edit /etc/apt/sources.list. The easiest thing is to copy the lines that start with "deb " and change the copies to "deb-src". | 18:46 |
| GrueMaster | Then run "sudo apt-get update" | 18:47 |
| MRSL | where is /ect? I tried to access the file and it says the directory doesn't exist. | 18:48 |
| GrueMaster | /etc not /ect. | 18:54 |
| MRSL | Bugger. Now I feel thick. Yay for sleep depravation!!! | 18:56 |
| GrueMaster | Heh. | 18:56 |
| anuvrat | hi | 19:01 |
| anuvrat | I am trying to create a custom root fs .. for FriendlyARM Tiny 6410 ... and facing kernel panic ... any direction on where to look will be very helpful | 19:02 |
| GrueMaster | Is it based on ubuntu? | 19:03 |
| MRSL | Alright, it started to download the source. so thanks again. | 19:05 |
| anuvrat | had run the ubuntu image, but given the limited capabilities of the board ubuntu was very slow ... so I was trying to get the simplest setup | 19:05 |
| anuvrat | GrueMaster: had run the ubuntu image, but given the limited capabilities of the board ubuntu was very slow ... so I was trying to get the simplest setup | 19:05 |
| anuvrat | GrueMaster: is there a way to strip the gui from ubuntu arm ... I mean strip it to tis bare skeleton ... so that my low end board would be able to use it | 19:06 |
| GrueMaster | if it is at least armv7, you can use the ubuntu-core image as a start for your rootfs. | 19:07 |
| GrueMaster | Or you could use an ubuntu-server image. They are headless and will even run on a Beagle C4. | 19:07 |
| anuvrat | GrueMaster: okay, thanks | 19:09 |
| anuvrat | GrueMaster: its arm 11 | 19:12 |
| anuvrat | http://www.friendlyarm.net/products/tiny6410 | 19:12 |
| GrueMaster | Ouch. We don't support anything lower than armv7 in our images. All binaries are built for this. | 19:13 |
| anuvrat | GrueMaster: so I start by downloading the ubuntu-core image | 19:13 |
| GrueMaster | It won't run on arm 11. | 19:13 |
| anuvrat | so v7 is higher than arm 11 | 19:14 |
| anuvrat | confusing arithmetic :P ... okay ... anyways .. any workarounds? | 19:14 |
| GrueMaster | Arm 11 is armv6 (iirc) architecture. Arm numbers were very confusing in the past. | 19:14 |
| GrueMaster | And no, we can't work around this without a complete rebuild. | 19:15 |
| GrueMaster | Won't happen any time soon. Not enough resources to rebuild & retest. We are having a hard enough time fixing all the broken packages for our current builds. | 19:16 |
| anuvrat | What I have been trying to do is get a system up with just busybox ... and my aim is to run python on the board and be able to use usb dongles for wifi and bluetooth on it | 19:17 |
| anuvrat | GrueMaster, any directions on how I should proceed | 19:17 |
| GrueMaster | You will probably want to use debian for binary packages. We simply can't help here. Beyond that, I have no suggestions. | 19:18 |
| anuvrat | Would it be completely crazy to try and build everything from source ... or would such an action drive me crazy via kernel panics ... what do you suggest? | 19:21 |
| anuvrat | GrueMaster: | 19:23 |
| GrueMaster | If you were to rebuild from source, again you would have to use something like Debian as our source is set to build armel & armhf, both of which are defined as armv7 in our build tools. | 19:24 |
| GrueMaster | And at this point you are no longer using ubuntu. Which is why I suggested debian. | 19:25 |
| anuvrat | GrueMaster: where on debian's site exactly do I go looking for its arm port ? I apologize if the intellectual standard of the questions is low ... | 19:32 |
| GrueMaster | I don't know. Try asking in #debian. | 19:32 |
| xranby_ac100 | anuvrat: if you want a minimal embedded system you should consider using openembedded | 19:36 |
| xranby_ac100 | anuvrat: if you want to use ubuntu try ubuntu-core | 19:37 |
| xranby_ac100 | ... friendly arm thats armv5 right? | 19:38 |
| GrueMaster | xranby_ac100: ubuntu-core is armv7 only. | 19:40 |
| smplman | anuvrat: i installed ubuntu from http://elinux.org/BeagleBoardUbuntu . I then install x11 and use ~/.xinitrc to launch my app when i startx | 19:43 |
| xranby_ac100 | anuvrat: which friendlyarm board do you got? | 19:44 |
| xranby_ac100 | i notice that some of their boards are based on a cortex-a8 | 19:44 |
| xranby_ac100 | like the http://www.friendlyarm.net/products/tiny210 this board can run ubuntu-core | 19:45 |
| smplman | i know on my xm the precise images boot to initramfs, havent had time to debug yet | 19:45 |
| smplman | xranby_ac100: looks like similar hardware specs to the beagle xm | 19:46 |
| === yofel_ is now known as yofel | ||
| anuvrat | xranby_ac100: smplman, GrueMaster I have FriendlyARM Tiny 6410 http://www.friendlyarm.net/products/tiny6410 | 20:38 |
| micahg | janimo`: seems that one of the build-deps of armel only, that should be [armel armhf] as kalikiana pointed out to me, I'll fix for the next upload | 20:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!