| === zyga is now known as zyga-afk | ||
| === ka6sox-away is now known as ka6sox | ||
| ka6sox | tmzt: if init? | 00:48 |
|---|---|---|
| ka6sox | as in sysV init? | 00:48 |
| ka6sox | yes | 00:48 |
| tmzt | yeah | 00:49 |
| ka6sox | yes, it works | 00:49 |
| tmzt | this is what I started on but I couldn't get it to work https://github.com/tmzt/nativenetbook-nativeinit | 00:50 |
| ka6sox | tmzt, have you heard of Optware? | 00:51 |
| tmzt | yeah | 00:51 |
| ka6sox | what happened is we ported optware to work on android | 00:51 |
| ka6sox | https://github.com/optware4android/nook-color | 00:52 |
| ka6sox | after a few iterations we had something that works. | 00:53 |
| ka6sox | so that gave me the ability to use things like ltrace and strace etc to look at porting. | 00:53 |
| ka6sox | and chroot | 00:53 |
| tmzt | ka6sox: I'm trying to get my X server to work with existing X sessions | 00:54 |
| tmzt | but xinit wants to start the server itself and mine runs outside of the chroot | 00:54 |
| ka6sox | then only "env" I bring into my chroots are /proc /sys and /dev as bind mounts | 00:55 |
| persia | tmzt, Do you mean that you want stuff launched in the chroot to be clients of an X server outside the chroot? | 00:55 |
| tmzt | yes | 00:55 |
| ka6sox | so nothing outside of that is available | 00:55 |
| tmzt | my X server androix.org runs as a native bionic aplication | 00:55 |
| tmzt | er, android application linked against bionic | 00:55 |
| persia | tmzt, I don't know much about android architecture, but you can usually get that to work if you can connect to the X server over the network or you bind-mount /proc: just export your desired DISPLAY | 00:56 |
| ka6sox | riht | 00:56 |
| ka6sox | er right | 00:56 |
| tmzt | I know, but the issue is I want to launch Xsession and also need things like a dbus system bus | 00:56 |
| tmzt | when I tried to do it it failed because it lost the controlling tty or other wise the forked children failed to run | 00:57 |
| ka6sox | tmzt, well...we have optware running *alongside* of android. | 00:57 |
| ka6sox | so somethings like that are possible. | 00:57 |
| tmzt | I'll look at it, I don't think most of the X clients are packaged though | 00:57 |
| persia | tmzt, If you need dbus, try bind-mounting /var/run | 00:57 |
| ka6sox | okay back to porting. | 00:58 |
| tmzt | android doesn't use dbus, so dbus would be running inside of the chroot | 00:58 |
| tmzt | anyway, thanks I'll look at this nook stuff and see if there's anything I can use | 00:58 |
| ka6sox | if nothing else it shows that you can run linux things with linux libs alongsiide of the android/bionic stuff. | 00:59 |
| ka6sox | hardcoded paths are a pain (like /lib/ld-linux.so | 01:00 |
| ka6sox | ) | 01:00 |
| ka6sox | but since their /lib doesn't contain that it doesnt matter. | 01:00 |
| === Amaranth_ is now known as Amaranth | ||
| tmzt | ka6sox: ah, so you aren't using a chroot? | 01:36 |
| ka6sox | for Ubuntu, yes, but optware is NOT a chroot | 01:36 |
| ka6sox | it all goes in /opt/ | 01:36 |
| ka6sox | and we bind mount to the rootfs | 01:37 |
| ka6sox | the only thing in the original rootfs is a few things that *have* to be in /lib and a small script that calls sysV init to get the optware services running | 01:38 |
| tmzt | that's in the git repo? | 01:39 |
| ka6sox | the one I pointed you to..yes | 01:39 |
| ka6sox | including sources | 01:39 |
| === Amaranth_ is now known as Amaranth | ||
| === Amaranth_ is now known as Amaranth | ||
| === Amaranth_ is now known as Amaranth | ||
| JamieBen1ett | exit | 06:13 |
| === ka6sox is now known as ka6sox-away | ||
| === zyga-afk is now known as zyga | ||
| === hrw|gone is now known as hrw | ||
| === ogra_ is now known as ogra | ||
| janimo_ | rsalveti, GrueMaster efl launcher I gave back a few hours after I saw it failed to upload. LP does not do that by default, and I am not sure why it failed in the first place | 10:31 |
| === amitk is now known as amitk-afk | ||
| === amitk-afk is now known as amitk | ||
| rsalveti | janimo_: oh, ok, good to know | 12:00 |
| ogra | http://www.fit-pc.com/trimslice/ | 14:13 |
| ogra | nice ! | 14:13 |
| LetoThe2nd | ogra: heise reader ;-) | 14:13 |
| ogra | heh | 14:13 |
| ogra | yeah | 14:13 |
| persia | Now that's a proper computer, in an appropriately shiny plastic case. | 14:32 |
| === zul_ is now known as zul | ||
| Homefix1 | sorry for the noob question, when starting qemu, is there something i can place in: "qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel ./vmlinuz -hda <whatever you name it>.img -m 256 -append "root=/dev/sda mem=256M devtmpfs.mount=0 rw" " to prevent the decktop from loadind (just give me command shell) thnx | 15:21 |
| ogra | between the quotes after append add text as a keyword | 15:24 |
| ogra | the login manager checks for that before firing up | 15:24 |
| Homefix1 | ogra: sorry for being thick, if your talking to me im lost i dont understand what you mean, could you give me an example? and if you were not responding back to me im sorry. | 15:30 |
| ogra | change rw" to rw text" | 15:30 |
| ogra | in the line above | 15:30 |
| Homefix1 | ogra thnx: i owe you coffie | 15:31 |
| Homefix1 | ogra: can i ask you one more thing? My machines hostname is Homefix, after running .img on my phone the promt is "dad@localhost" instead of "dad@Homefix. I have my /etc/hosts file setup correctly "127.0.0.1 localhost Homefix".I have /etc/hostname setup correctly "Homefix" is my problem here in the chroot startup script here: | 15:41 |
| Homefix1 | echo "Setting /etc/resolv.conf to Google Open DNS 8.8.8.8 and 8.8.4.4" | 15:41 |
| Homefix1 | echo "nameserver 8.8.8.8" > $mnt/etc/resolv.conf | 15:41 |
| Homefix1 | echo "nameserver 8.8.4.4" >> $mnt/etc/resolv.conf | 15:42 |
| Homefix1 | echo "Setting localhost on /etc/hosts " | 15:42 |
| Homefix1 | echo "127.0.0.1 localhost" > $mnt/etc/hosts | 15:42 |
| Homefix1 | echo "127.0.0.1 localhost" > $mnt/etc/hosts | 15:42 |
| Homefix1 | ? | 15:42 |
| ogra | localhost always needs to be there | 15:42 |
| Homefix1 | ok thns | 15:42 |
| ogra | adding a line like: 127.0.1.1 Homefix | 15:43 |
| ogra | to /etc/hosts should give you the desired outcome | 15:43 |
| Homefix1 | ok thought i did that try again thnks | 15:45 |
| ogra | (note the 1.1 at the end of that IP) | 15:45 |
| Homefix1 | no i didnt just noticed the 1,0 | 15:46 |
| Homefix1 | 1.1 | 15:46 |
| Homefix1 | ogra I promise only 1 more quest. How come when starting the chroot in my android terminal, i get the promt "root@localhost" the i login as dad and get, "dad@localhost", I start vncserver as dad@..., then sesssion starts, i use vnsviewer set up as dad for "nik", localhost for "hostname", my vnc password then connect. I get to desktop logged in as root and the root desttop. I have setup | 15:58 |
| Homefix1 | HOME=/home/dad and USER=dad in the startup scripts (that are here:http://forum.xda-developers.com/showthread.php?t=913622)<<<<< those entries are entered as "root", I changed my entries to "dad" and added export USER=dad to "bootubuntu"............ | 15:58 |
| Homefix1 | ogra: is ther a way to get looged in as dad instead of root? | 15:58 |
| ogra | chroot always makes you root in the target fs | 15:59 |
| Homefix1 | k | 15:59 |
| ogra | but you can run "su dad" | 15:59 |
| ogra | that should make you dada | 15:59 |
| ogra | heh | 15:59 |
| ogra | dad i mean | 15:59 |
| Homefix1 | haha | 15:59 |
| Homefix1 | i just log in as dad in the chrooted term. | 16:00 |
| Homefix1 | can i take a rootstock build 1G .img , turn it into a 3G image? | 16:08 |
| * persia notes that chroot takes a --userspec argument if one wants to be non-root for some reason. | 16:09 | |
| ogra | oh, i didnt know that :) | 16:10 |
| persia | It's exceedingly rarely useful: primarily only when embedding the chroot call in some other utility. | 16:11 |
| ogra | persia, btw | 16:11 |
| ogra | Description: The Unity 2D interface for non-accelerated graphics cards | 16:11 |
| ogra | This package installs a fully usable Unity 2D session and provides the | 16:11 |
| ogra | common configuration files and defaults. Installing this package will | 16:11 |
| ogra | offer the Unity 2D session in your login manager. | 16:11 |
| ogra | . | 16:11 |
| ogra | Unity 2D is designed to run smoothly without and graphics acceleration. | 16:11 |
| ogra | thats my final text now | 16:11 |
| persia | No. | 16:11 |
| ogra | waiting for kaleo to process the merge request | 16:12 |
| persia | It expects 2D acceleration, it just doesn't require 3D acceleration. | 16:12 |
| ogra | it doesnt | 16:12 |
| persia | Try running it on unaccelerated framebuffer and you *will* feel pain. | 16:12 |
| ogra | xfbdev doesnt have any 2d accel | 16:12 |
| ogra | thats what i'm doing here | 16:12 |
| GrueMaster | persia: I do run it on unaccelerated 2D fame buffer. | 16:12 |
| persia | Yes it does: it was added to trunk in 2004 | 16:12 |
| Homefix1 | its happened again, i was having problems not getting a "prompt" in the terminal of the chrooted image i made a with rootctock....tried again last night it worked but the image was too small. tried again made it 3G but now no prompt...eGGgghh..... any suggestions why i canot get a prompt in the terminal with one image but not another? | 16:13 |
| persia | GrueMaster, Really? Not xfbdev? | 16:13 |
| GrueMaster | Not in VM. | 16:14 |
| GrueMaster | It is using the Xsvga driver iirc. | 16:14 |
| persia | Oh, indeed. And the performance there is acceptable? | 16:14 |
| GrueMaster | Seems to be. | 16:14 |
| * persia is impressed. | 16:14 | |
| ogra | well, it is very likely that people not having 3d accel end up with fbdev | 16:15 |
| persia | ogra, So, three things about the Description then: | 16:15 |
| ogra | i think thats our default fallback for cards without any driver | 16:15 |
| persia | 1) The short description (after "Description:") should complete the cloze ${package} is a ${short-description}. Repeating "Unity 2D" is frowned upon (although you've used it a bit differently, so might argue you mean "Unity" and "2D" separate from "Unity 2D") | 16:16 |
| persia | 2) The prefatory phrase "This package" is useless drivel, and confusing for package mangagement tools that don't give the user the package name. Start exciting and juicy. | 16:17 |
| persia | (hint: inserting "The Unity 2D interface" may help) | 16:17 |
| ogra | i thought there were reasons why these complaints were removed from lintian | 16:17 |
| persia | 3) s/and/any/ in the last sentence. | 16:17 |
| ogra | uh, yeah | 16:18 |
| persia | I thought they were removed to make people like me less picky. | 16:18 |
| ogra | i'll change that with the upload after the merge was done | 16:18 |
| persia | Heh, sure. No rush. | 16:18 |
| ogra | i dont want to file a new merge request right now | 16:18 |
| persia | You can just update them, you know. | 16:19 |
| persia | (there's even some handy UI in LP for that) | 16:19 |
| ogra | there are other typos in the control file i need to fix anyway | 16:19 |
| GrueMaster | wait, there are other people as picky as you, persia? :P | 16:19 |
| ogra | which i planned to do in a subsequent upload | 16:19 |
| ogra | GrueMaster, IRS | 16:19 |
| ogra | ;) | 16:19 |
| persia | GrueMaster, I believe myself to only be in the 92nd percentile of pickiness. | 16:19 |
| GrueMaster | heh | 16:19 |
| Homefix1 | can i turn a 1g rootstock image into a 3G (made filesize too small) | 16:28 |
| === ka6sox-away is now known as ka6sox | ||
| ogra | persia, | 16:47 |
| ogra | Description: Unity interface for non-accelerated graphics cards | 16:47 |
| ogra | The Unity 2D interface installs a fully usable 2D session and provides the | 16:47 |
| ogra | common configuration files and defaults. Installing this package will | 16:47 |
| ogra | offer a session called Unity 2D in your login manager. | 16:47 |
| ogra | . | 16:47 |
| ogra | Unity 2D is designed to run smoothly without any graphics acceleration. | 16:47 |
| ogra | better ? | 16:47 |
| Homefix1 | ogra I fixed it but why would i one image require "mount --bind /dev $mnt/dev" in the startup scriptand another made the same way not need it? could it have somthing to do with the programs i install in qemu? I just dont get it? | 17:11 |
| ogra | no idea, i dont know who made these startup scripts | 17:13 |
| ogra | generally you should bind mount /dev into the chroot to be able to access devices though | 17:14 |
| prpplague | ogra: http://www.engadget.com/2011/01/25/compulab-makes-a-tiny-tegra-2-computer-for-the-lilliputian-commu/ | 18:07 |
| prpplague | ogra: seen that? | 18:07 |
| ogra | yep | 18:07 |
| ogra | <ogra> http://www.fit-pc.com/trimslice/ | 18:07 |
| ogra | <ogra> nice ! | 18:07 |
| ogra | ;) | 18:08 |
| prpplague | ogra: man, that looks nice | 18:08 |
| ogra | sadly the kernel situation for tegra is very very far from being usable | 18:08 |
| * prpplague can't wait to order one | 18:08 | |
| prpplague | ogra: that will change when people get a trimslice and start doing dev | 18:09 |
| ogra | i suspect they will come with a 2.6.29 or 2.6.32 kernel | 18:09 |
| ogra | that wont help with the proprietary drm driver or xserver | 18:09 |
| ogra | as long as nvidia doesnt work with the community and compiles against some decent kernel or xorg | 18:10 |
| prpplague | ogra: ahh wasn't aware of the proprietary drm driver stuff | 18:10 |
| ogra | currently to make X work accelerated on tegra you need to apply their overlay FS (a tarball) with ancient xorg versions and libs | 18:10 |
| ogra | and their kernel module is only compiled for two or three old kernel versions | 18:11 |
| prpplague | ogra: ahh but that is for accelerated, without works right? | 18:11 |
| ogra | i wish they would provide a shim so we could use dkms to just build it against the kernel we ship | 18:12 |
| ogra | sure, plain framebuffer works fine | 18:12 |
| ogra | thats what i use on the ac100 | 18:12 |
| ogra | but its sad that i cant use the full power of the device due to silly management decisions at the manufacturer | 18:12 |
| ogra | their whole sound, powermanagement and cup speed control is done by a proprietary daemon in userspace | 18:14 |
| ogra | *cpu speed | 18:14 |
| ogra | i really love TI for its openess | 18:14 |
| GrueMaster | ogra: I have seen some alsa patches recently for the tegra. Hopefully they will be in 2.6.38 or 39. | 18:14 |
| rsalveti | hehe, I'd say they will get something for 40 | 18:15 |
| ogra | GrueMaster, wont help, the codecs are binary inside the daemon | 18:15 |
| rsalveti | or even alter on | 18:15 |
| rsalveti | with luck omap 4 is going to be kind of fine for 38/39 | 18:15 |
| ogra | GrueMaster, the kernel side only provides hooks for them | 18:15 |
| rsalveti | :-( | 18:16 |
| ogra | i wouldnt mind all that if nvdidia would at least provide binaries against decent versions of all that | 18:17 |
| ogra | but what they offer is massively outdated | 18:17 |
| prpplague | ogra: yea omap4 should be pretty robust, just love that trimslice package | 18:19 |
| ogra | yup | 18:19 |
| GrueMaster | ogra: What I'm seeing is patches in the last few weeks directly from nvidia to alsa. From what I can tell, they are exposing the gpio's to the codec and tweaking the codec driver as well. | 18:20 |
| ogra | right, but the binary bits come from the userspace daemon | 18:21 |
| ogra | i have sound devices on the ac100 too ... they just dont route to anything unless i get the daemon running | 18:21 |
| ogra | (silence and pules at 100% cpu) | 18:22 |
| ogra | *pulse | 18:22 |
| GrueMaster | That is the non-alsa driver. They removed it post 2.6.36. | 18:22 |
| pH5 | hi, has anybody compiled qt4-x11 with -opengl es2 support yet? | 18:22 |
| ogra | pH5, rsalveti works in that | 18:22 |
| ogra | not sure there is a ppa with the packages | 18:23 |
| rsalveti | pH5: yup, currently debugging that with sgx | 18:23 |
| rsalveti | yup, we have, let me get the link | 18:23 |
| rsalveti | https://launchpad.net/~rsalveti/+archive/qt-neon-gles | 18:23 |
| rsalveti | natty and maverick | 18:23 |
| pH5 | ogra, rsalveti: ow, great. thanks! | 18:24 |
| rsalveti | np | 18:24 |
| armin76 | nice, it has gigabit | 18:24 |
| ogra | the ppa ? | 18:24 |
| rsalveti | :P | 18:24 |
| ogra | :) | 18:24 |
| KC9SJQ | Howdy all | 18:51 |
| KC9SJQ | I have some questions about the wireless system | 18:51 |
| ogra | ask then :) | 18:52 |
| KC9SJQ | I'm attempted to setup a pandaboard as a router, with a bridge between the built in ethernet and wifi | 18:52 |
| KC9SJQ | unfortunately, it seems like the wireless isn't supported | 18:52 |
| ogra | it is | 18:52 |
| ogra | did you install the ti addons ? | 18:53 |
| KC9SJQ | when I define it via /etc/networks/interfaces as master | 18:53 |
| KC9SJQ | oh, I did, it worked as a client before I start playing with networking | 18:53 |
| ogra | ah, i haven used the wlan without NM yet | 18:53 |
| ogra | but i suspect you need wpa_supplicant setup or some such | 18:54 |
| KC9SJQ | The line that conserns me is "no (wireless) mapping found for key: wireless-mode | 18:55 |
| ogra | wait, you said master, you mean AP mode ? | 18:56 |
| KC9SJQ | wpasuplicant is installed, and I think I have it set as an open ap | 18:56 |
| KC9SJQ | yes, that is correct. master as in ap | 18:57 |
| ogra | i know rsalveti provided AP mode to me in dallas through his panda so it definitely works somehow | 18:57 |
| ogra | but that might have been through NM as well | 18:57 |
| rsalveti | ogra: that was n900 | 18:57 |
| ogra | the panda network ? | 18:58 |
| rsalveti | but using nm at my host | 18:58 |
| rsalveti | yup | 18:58 |
| ogra | i thought you used the panda for the ap stuff ... ok | 18:58 |
| rsalveti | never tried to use the panda wifi chip as ap | 18:58 |
| ogra | me neither | 18:58 |
| rsalveti | the driver wasn't stable at that time | 18:58 |
| rsalveti | lots of kernel panics all around | 18:58 |
| ogra | i also dont know if the driver from the ppa is actually built against mac80211 | 18:59 |
| ogra | then you could use hostapd | 18:59 |
| rsalveti | maybe you will get better results with current upstream one | 18:59 |
| ogra | definitely | 18:59 |
| KC9SJQ | What is that, do you have a link? | 18:59 |
| ogra | http://groups.google.com/group/pandaboard/browse_thread/thread/291bf9cbd8c36d15 | 19:00 |
| ogra | that ppa should have newer stuff | 19:00 |
| ogra | sudo add-apt-repository ppa:tiomap-dev/omap-trunk | 19:01 |
| * KC9SJQ looks | 19:01 | |
| ogra | not sure if it already has the new wifi driver though | 19:01 |
| ogra | might be that this is only upstream | 19:01 |
| * KC9SJQ adds to mirror and updates | 19:03 | |
| KC9SJQ | I'll let that chug while I get a sandwich. | 19:04 |
| KC9SJQ | Thanks for the help. | 19:05 |
| ka6sox | okay lets see what explodes when I boot this puppy | 19:16 |
| persia | ogra, The new description looks good to me. Publish it :) | 19:26 |
| ogra | persia, heh, to late | 19:26 |
| ogra | already sitting in NEW | 19:26 |
| ogra | i need to talk kaleo into a new upstream release before i can MIR them though | 19:27 |
| ogra | i dont want to have bits in debian/patches for the MIR | 19:27 |
| ogra | but thats for tomorrow | 19:27 |
| * ogra really likes bzr builddeb --split :) | 19:27 | |
| persia | --split is *not* the right way to do it. I forget why, but that was the conclusion from the discussion between NCommander and james_w. | 19:31 |
| ogra | persia, --split is what upstream insists to be used, they also insist to have the debian dir in the branch, only tarball releases wont have it | 19:39 |
| persia | Dunno. Talk to one of the folks I listed above. I just remember hearing it wasn't the right way to do it after that conversation. | 19:40 |
| ogra | well, it works great and makes life a lot easier | 19:41 |
| persia | It does something messy and bad when attempting to handle coordination between the branch importer and the upstream branch. | 19:41 |
| persia | But my understanding of UDD is too weak to know precisely what. | 19:42 |
| persia | The key bit is that I believe it blocks direct cherrypick from upstream to the import branch. | 19:42 |
| ogra | well, i'll go with upstream if they insist, who am i to complain if it makes my life easier | 19:42 |
| ogra | ah, well, there is no import branch | 19:43 |
| persia | There will be as soon as it passes NEW. | 19:43 |
| ogra | thats the main argument, they want a single branch per project | 19:43 |
| persia | Seriously, go get some UDD Kool-Aid. You'll be in a lot better shape to discuss this with upstream. | 19:44 |
| persia | It will be better for you and better for them to take advantage of the import branch. | 19:44 |
| ogra | doesnt help me with upstream, really | 19:44 |
| ogra | you mean they should merge back from the package branch ? | 19:44 |
| ogra | into trunk | 19:44 |
| persia | I mean that because bzr doesn't support parallel trees, it won't support operations between the import branch and the upstream branches if you use --split. | 19:45 |
| persia | As in an error message with `bzr merge`. Simply no support for it at all. | 19:46 |
| ogra | no, you need to merge the import branch before doing a new upstream indeed | 19:46 |
| ogra | hmm ? | 19:46 |
| ogra | why shouldnt it merge anymore | 19:46 |
| ogra | the content stayed consistent | 19:47 |
| persia | You *can't* if you created with --split. If upstream creates an artifact tarball, it can be done, but with --split, the tarball is semi-random, and the history is unrecoverable. | 19:47 |
| persia | But I don't know enough about this: please ask someone knowledgeable. | 19:47 |
| persia | bzr doesn't use the content as part of merging. | 19:47 |
| persia | Yes, that sounds odd, but it's true. If you ask the bzr folk, they'll tell, you about the parallel merge problem, and how it's the very first thing they fix after changing the on-disk format of bzr. | 19:48 |
| persia | But until the data format is fixed, it's not possible. | 19:48 |
| persia | Has to do with inode tracking and other internal complexities. | 19:48 |
| ogra | the point is that there are no merges at all happening from anything after the package was uploaded | 19:49 |
| ogra | packaging changes are done in a local branch, merged into trunk, then trunk is pulled and built with --split | 19:49 |
| persia | Don't argue with me: even if you were capable of convincing me, it wouldn't help. Talk to someone who understands UDD. | 19:49 |
| ogra | UDD isnt involved at all atm | 19:49 |
| persia | I just don't know enough to argue with you about this. | 19:49 |
| ogra | i dont argue | 19:50 |
| persia | Sorry: s/argue/debate/ | 19:50 |
| ogra | but you tell me the way that is used breaks with UDD | 19:50 |
| * persia didn't intend any indication of emotional involvement | 19:50 | |
| ogra | and i tell you that UDD isnt involved in the current setup | 19:50 |
| ogra | so i dont need to talk to UDD people yet :) | 19:50 |
| persia | If UDD is used and inherited from upstream history, it becomes easy to cherrypick individual commits, and have those applied as distro-patches, etc. | 19:51 |
| persia | Otherwise it's all manual manipulation. | 19:51 |
| ogra | thats what it is atm | 19:51 |
| persia | Since there *will* be a packaging branch, and since people *will* submit merge requests from their branches fixing bugs, it makes sense to try to make sure that things can be pulled/pushed back and forth. | 19:51 |
| ogra | and there are no such things like distro patches given the fact that everything happens in trunk | 19:51 |
| persia | Mind you, I'm a fan of manual manipulation. I tend to use bzr as a way to track the patches I applied, rather than as a VCS, but still. | 19:52 |
| ogra | i think upstream will change their mind if the first external distro shows up to use their stuff | 19:52 |
| persia | ogra, Saying there are no distro patches implies you have control over the set of folks commiting branches and uploading, which isn't the case. | 19:52 |
| ogra | and they have to keep distinct branches for ubuntu and "others" | 19:52 |
| ogra | we do have that control atm | 19:53 |
| ogra | it wont staxy that way and i didnt want to argue with upstream | 19:53 |
| ogra | so i went with what they asked for | 19:53 |
| persia | Anyway, talk to the UDD people, just so you see the points. I can't explain why --split isn't preferred in a sensible way. | 19:57 |
| ogra | k | 19:57 |
| KC9SJQ | Hmm, update failed | 20:49 |
| KC9SJQ | error building module pvr-omap4-kernel | 20:50 |
| KC9SJQ | error: 'struct platform_device' declared inside parameter list | 20:55 |
| KC9SJQ | any thoughts? | 20:56 |
| rsalveti | KC9SJQ: what kernel are you using? | 21:22 |
| KC9SJQ | I can't tell anymore, my board now won't boot. | 21:22 |
| KC9SJQ | it should have been the official one from the ubuntu arm repositories | 21:23 |
| KC9SJQ | I guess I'll have to rebuild the card | 21:24 |
| KC9SJQ | It appears to start booting, and then gets stuck with some fsck info on the screen | 21:24 |
| rsalveti | hm | 21:27 |
| rsalveti | I know the pvr kernel module is compatible with our tree | 21:27 |
| rsalveti | as the needed patches are applied | 21:27 |
| rsalveti | if you're using a different one, then you need to make sure you get everything | 21:27 |
| rsalveti | KC9SJQ: you can easily boot our default kernel by installing it at your sd card | 21:28 |
| KC9SJQ | So far, I've been trying to do it via the idiot method, add a repository and update | 21:28 |
| rsalveti | using qemu and chroot | 21:28 |
| KC9SJQ | Kernel 2.6.35-903-omap4 | 22:09 |
| KC9SJQ | What is "your kernel" and how can I get it? | 22:11 |
| persia | The linux-image-omap4 package should always depend on the latest omap4 kernel in Ubuntu. | 22:17 |
| KC9SJQ | That should be the default, and I haven't changed it | 22:20 |
| KC9SJQ | yeah, "linux-image-omap4 is already the newest version" | 22:21 |
| KC9SJQ | I wonder if I'm missing the headers or something | 22:22 |
| KC9SJQ | if the module is missing a unspecified dependancy | 22:22 |
| persia | Odd. It ought just work. | 22:28 |
| * KC9SJQ shrungs | 22:29 | |
| KC9SJQ | does the omap-trunk ppa automatically rebuild on a particular basis? | 22:30 |
| KC9SJQ | Maybe it's a legitimate bug which will be fixed soon | 22:30 |
| persia | The PPA won't rebuild on a regular basis. But some of the team that maintains the PPA might upload occasionally. | 22:32 |
| persia | There's no way to file bugs on PPA packages, but you might be able to look at the name of the last uploader in the changelog, and find them in this channel. | 22:33 |
| NCommander | persia: the reason was --split is braindead. Proper way to do it is pristine-tar | 23:02 |
| persia | Right, which requires a tarball. Anyway :) | 23:03 |
| NCommander | persia: at some point I was going to through the 0.1 orig.tar.gz tarball I made via split into pristine-tar | 23:04 |
| NCommander | woo | 23:04 |
| NCommander | My build finally finished | 23:04 |
| * NCommander thinks we have a compiler regression ... | 23:30 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!