[00:54] <plars> ogra: sorry, was away... will test tonight if you haven't already
[00:57] <crimsun> plars: I haven't had time to look at the straces for the PA bug; when you run using sudo, what's holding /dev/snd/* open?  (sudo fuser -v /dev/snd/*)
=== debio264_ is now known as debio264
[02:49] <peterkirn> apologies if this question was posted before; my cable just went out. anyone have any issues setting up sudo/su on rootstock?
[02:50] <rcn-ee> peterkirn, what's it not doing?
[02:52] <peterkirn> well, when I created the root file system, I set up flags for userid and pwd. those work to login, but the pwd fails on su - and sudo returns no root privs
[02:53] <peterkirn> that is, sudo rootstock with flags --login userid --password pwd to create the image
[02:55] <rcn-ee> that's strange...  it worked for me with an image last week.. rootstock sets up the defined user with sudo privledges...
=== rsalveti_ is now known as rsalveti
[02:56] <peterkirn> su returns an authentication error for that password; sudo returns "must be setuid root"
[02:58] <peterkirn> "/usr/bin/sudo" is root:root... that's right, yes?
[02:58] <rcn-ee> that's strange... i had a user with the same issue on the beagleboard forum today,...
[02:58] <rcn-ee> digs for the link..
[02:59] <peterkirn> yeah, this is a hawkboard. ;) of course, could be our lack of experience (I'm not completely green, but...)
[02:59] <rcn-ee> it was thisone: http://groups.google.com/group/beagleboard/browse_thread/thread/a2eea0446fab84ce/3ff6c6f16fce7874?lnk=gst&q=sudo#3ff6c6f16fce7874  that's two in a row...
[03:00] <rcn-ee> he was using karmic, and your using jaunty....  different versions of sudo..
[03:01] <rcn-ee> did you 'sudo tar xjfp'  when you extracted the file system?
[03:01] <peterkirn> reading, thanks! well, I think the hawkboard is so far happy only with jaunty. I am building jaunty under karmic rootstock, though.
[03:02] <peterkirn> sudo tar xfp, yes
[03:02] <rcn-ee> yeah that should be fine..  running lucid...
[03:02] <rcn-ee> stumped..  same problem, no connection, he used my demo image and your using rootstock...
[03:03] <rcn-ee> if it keeps happening i'd file a bug with rootstock...
[03:04] <peterkirn> I got even more aggressive, tried chmod 777 for the whole stick
[03:05] <peterkirn> anything else to try, in the meantime?
[03:06] <rcn-ee> give one of my ancient builds a try, it works for a year on the beagle: http://rcn-ee.net/deb/rootfs/ubuntu-9.04-minimal-armel.tar.7z
[03:06] <rcn-ee> user: ubuntu pass: temppwd  just add your own hawkboard kernel..
[03:06] <peterkirn> I'll try chmod chown on sudo again, too, apparently sometimes repeat goes at it help
[03:07] <rcn-ee> you might have to set the permissions from your other pc..
[03:07] <peterkirn> yep, will give that a try, too. what size is it? glad I had my droid handy during yet another internet outage on timewarner. ;)
[03:08] <peterkirn> thanks!
[03:08] <rcn-ee> it's 66Mb..  just a simple console demo image...
[03:09] <peterkirn> ok, great. will let you know what happens and see if it makes sense to open a ticket.
[03:09] <rcn-ee> i built that image with build-arm-rootfs so we might be seeing a regression..
[03:10] <peterkirn> yeah; I will definitely compare results with each
[03:12] <peterkirn> ah, that's weird.
[03:13] <peterkirn> if I sudo chmod 4111 /usr/bin/sudo on my pc, I get must be setuid root
[03:15] <persia> I've encountered this before, when a filesystem was copied to VFAT, and then copied to something sane again.
[03:15] <persia> Dunno if that is the cause this time, but ...
[03:16] <peterkirn> hmm, interesting. well, for me, only ext3
[03:16] <persia> Then definitely a different issue.
[03:18] <rcn-ee> i think it's just somethign with today, another user on the beagleboard group is having login problem with gdm in lucid...
[03:18] <peterkirn> ah, must be I actually have something screwy on this karmic laptop. on my fedora machine, no problem.
[03:19] <peterkirn> there was that big magnetic storm today. ;) okay, now seeing if it works booting on the hawkboard.
[03:22] <peterkirn> but, yes, that'd explain it... it simply inherited the permissions problem from this laptop.
[03:31] <peterkirn> hmmm, that didn't help with the issue, but I'll take some time and try with the other image.
[03:50] <plars> rcn-ee: hi, was looking at bug 541030, perhaps I'm looking at a different tree but I don't find a commit b586f759f4dda7622a90f68c9c05424e777b8b2b that you reference in there, which tree are you looking at, and what is that changeset doing that you revert?
[03:50] <ubot4> Launchpad bug 541030 in linux-ti-omap (Ubuntu Lucid) (and 1 other project) "omap kernel musb/ehci ports not enabled on beagleboard (affects: 1) (heat: 12)" [Critical,Triaged] https://launchpad.net/bugs/541030
[03:51] <rcn-ee> Hi plars, i've narrowed that commit down some more, i'll push a couple more notes...  that commit is: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=b586f759f4dda7622a90f68c9c05424e777b8b2b
[03:51] <rcn-ee> it's in the ti-omap branch...
[03:52] <plars> rcn-ee: ah, I see, thanks!
[03:52] <rcn-ee> no problem..  it's a fun CONFIG, since enable a couple options waterfalls more, so lots of tweaks..
[04:10] <rcn-ee> plars, i'll dig into it more tomorrow... but i have that commit seperated into a safe commit and a broken commit.. However part of the broken commit can still be salvaged (OTG setting) Just got to re-figure out the correct config sequence that works..
[05:58] <DanaG> hmm, now that the dl5 kernel doesn't have the g_* drivers as modules... now I can't load g_audio.
[06:13] <NCommander> eggonlea: you around?
[07:39] <eggonlea> NCommander: ack
[08:37] <nosse1> Hi guys. How do you kick off ubuntu (with initrd) from u-boot?
=== jamie is now known as Guest97591
=== Guest97591 is now known as JamieBennett
[08:40] <nosse1> The important part is how you load the initrd image
[08:43] <persia> nosse1: It really depends on which uboot and where the initrd is stored.
[08:45] <nosse1> persia: I'm running U-boot 2009.11 (for AM3517 by TI) and I have options for where to store the initrd
[08:46] <nosse1> Currently its on an NFS server, like the kernel image, but I can move it if neccessary
[08:47] <nosse1> Point is, do you load the initrd to memory using u-boot and then pass the address for it to the kernel?
[08:48] <persia> That certainly ought work (e.g. "initrd=0x11700000,8M"), but I'm not sure if it works without the initrd load.
[08:48] <amitk> nosse1: you'd provide two addresses to 'bootm' - kernel and initrd
[08:49] <nosse1> amitk, ok. Do you need to supply the initrd address in the kernel parameters?
[08:49] <amitk> nosse1: no AFAIK
[08:49] <nosse1> I'll try that. Thanks
[08:55] <DanaG1> http://elinux.org/Talk:BeagleBoardUbuntu
[08:55] <DanaG1> check that... even if you're on a different board.
[08:56] <amitk> right, elinux has some good instructions on generic board bringup
=== hrw|gone is now known as hrw
[08:56] <hrw> morning
[09:00] <amitk> morning
=== andruk is now known as suckage
=== XorA|gone is now known as XorA
=== suckage is now known as andruk
[11:10] <nosse1> How do you generate the initrd image for u-boot? The /boot/initrd.img file is a gzipped cpio archive, and when I load it U-boot complains about "wrong ramdisk image format"
[11:11] <XorA> nosse1: you need to run mkimage from uboot-utils
[11:11] <nosse1> Ah, so the initrd must be mkimagized as well....
[11:12] <XorA> I beleive so
[11:12] <XorA> for some wierd reason
[11:18] <persia> Is that a uboot limitation, or something fixable?
[11:19] <amitk> persia: u-boot requires it for kernel, initrd, bootscript
[11:20] <amitk> it hads a 64 byted header to each
[11:20] <amitk> s/hads/adds
[11:20] <persia> Makes sense, although unfortunate.
[11:20] <amitk> a minor annoyance, admittedly. But I script it away.
[11:21] <persia> Is that the sort of thing that would make sense as a rootstock option?
[11:23] <amitk> is it the job of rootstock to give a dd'able sd image? If not (as I suspect), then no
[11:24] <persia> No, rootstock only generates rootfs tarballs.
[11:24] <nosse1> eh? I have generated ext2 images from rootstock that I've dd-ed to target. Works fine.
[11:25] <nosse1> (well.. fine is somewhat an overstatement: I'm still working on bringing up the system)
[11:26] <persia> nosse1: Indeed.  rootstock is good at what it does.  The point being that it *isn't* the tool to generate images, but only filesystems.
[12:14] <nosse1> rootstock can build an image/tarball using a custom kernel (from a deb file). How can I generate such a deb from my custom kernel source?
[12:15] <nosse1> I can copy the debian.* dirs from the ubuntu lucid kernel source (and use e.g. the ti-omap branch). However I dont know how to get from these source to a deb file :(
[12:15] <persia> debuild -b
[12:16] <persia> Or us pbuilder or sbuild for a clean build environment.
[12:20] <hrw> nosse1: make-kpkg is a tool
[12:21] <hrw> from kernel-package
[12:23] <amitk> make-kpkg is not supported by Ubuntu, infact we will discourage its use
[12:24] <hrw> what does replace it?
[12:24] <persia> debuild -b
[12:24] <hrw> but debuild require debian/ dir - right?
[12:24] <persia> Yes.
[12:24] <hrw> and make-kpkg creates such when not present
[12:25] <amitk> hrw: the ubuntu kernel uses its own buildsystem (based on debuild) and has its own way of managing configurations
[12:26] <hrw> ok
[12:27] <amitk> https://wiki.ubuntu.com/KernelTeam/KnowledgeBase <--- lots of info about maintaining ubuntu kernels
[12:27] <amitk> and other stuff..
[12:33] <nosse1> My biggest challenge in this respect has been to ubuntuize a vanilla or 3rd party kernel in order to make it run ubuntu on target
[12:33] <nosse1> But I seem to make progress in this respect now
[12:33] <hrw> ok
[12:34] <nosse1> Will Lucid be release for ARM as well (for the 10.04 LTS release date)?
[12:34] <JamieBennett> nosse1: yes
[12:34] <JamieBennett> we have the same release date
[12:34] <nosse1> :D
[12:35] <nosse1> Do you have a defined list of supported targets/machines for this release?
[12:36] <nosse1> I.e. I have an AM3517-evm which the lucid kernel image (ti-omap) is not working currently.
[12:37] <JamieBennett> nosse1 Freescale iMX51 and Marvell Dove platform are the officially supported arches
[12:37] <nosse1> ok
[12:38] <JamieBennett> and omap (beagle board)
[12:38] <nosse1> Is this based on EVM availability?
[12:38] <JamieBennett> basically what ever image you see here - http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/
[12:39] <nosse1> Can EVM donation to key developers help addition of support for other HW?
[12:39] <amitk> nosse1: it's based on what is considered a priority for the first release of OMAP (and yes that includes HW availability)
[12:40] <JamieBennett> nosse1: outside of our official images, any hardware enablement would be on a developers own time
[12:41] <amitk> nosse1: donations are unlikely to help at this point (very close to release) but we'd appreciate QA help and bugs regarding what is _not_ working
[12:41] <nosse1> Ah, so it has been a policy decision to support iMX, Marvell and beagle board.
[12:42] <nosse1> Point is, we're building a product based on the AM3517, and of course we'd like to see official support for that target
[12:42] <amitk> nosse1: policy in terms of contracts, yes
[12:42] <nosse1> Again, porting is WIP, so I will have more info of what works and not works later
[12:42] <rcn-ee> nosse1, what's that board currently doing on bootup? I don't have any of the Logic based boards..
[12:43] <nosse1> AM3517-EVM from TI, which is a Zoom AM3517 eval kit
[12:43] <persia> nosse1: If you can find a config that supports AM3517, and also supports the beagleboard for the Ubuntu kernel source, please submit a patch that does that.
[12:43] <amitk> nosse1: I've said in the past, I think - point me to patches that will make your board work better (I think the base kernel should just boot) and I'll consider it
[12:44] <amitk> nosse1: there shouldn't be any _porting_ involved IMO if this a basically an EVM board
[12:44] <nosse1> amitk, Yes I know, and thanks. I will supply more info/patches/etc. when we get there.
[12:44] <robclark> nosse1: isn't AM35xx pretty similar to OMAP35xx?
[12:44] <amitk> (assuming same peripherals, ofcourse)
[12:45] <robclark> I guess same filesystem would have high likelihood of working, if you had a suitable xload/uboot/uImage
[12:45] <hrw> JamieBennett: you work @canonical now?
[12:45] <nosse1> Yes, I think so. It's just tailored for industrial instead of commercial/mobile
[12:45] <robclark> ok, that is what I thought..
[12:46] <nosse1> The question is if Ubuntu will accept patches and fixes to a HW which is not officially supported, that all
[12:46] <persia> It ought be possible to construct a kernel that works for either, but xload/uboot will surely differ.
[12:46] <JamieBennett> hrw: yes
[12:46] <robclark> well, if you ignore accelerators (not sure if AM35xx has DSP?)... userspace should be quite similar
[12:46]  * XorA normally finds the same rootfs can boot on many many different boards if udev is working right
[12:46] <robclark> yup
[12:46] <persia> nosse1: As long as 1) it doesn't break anything, 2) if complies with freezes, and 3) it doesn't require more trees, probably.
[12:47] <amitk> nosse1: YES we will accept patches. But not necessarily all of them :)
[12:47] <nosse1> The vanilla debian lucid kernel for ti-omap does not work (it crashes). I have to use a 2.6.32 kernel supplied by TI. I have not investigated the extent of patches between the ti-omap ubuntu kernel and the one from TI
[12:48] <nosse1> My guess is that when we have overcome the kernel obstacle, hopefully Ubuntu will work OOB
[12:48]  * hrw -> printer for some papers to read/sign
[12:48] <persia> You'll need to do that investigation.  Especially this late in the cycle, patches that aren't known to work also for supported boards are very unlikely to be accepted.
[12:49] <nosse1> Thats why I asked if ARM is releasing together with 10.04... :D
[12:50] <persia> All the architectures have the same schedule.  They are all based on the same sources, uploaded at the same time.
[12:50] <persia> We happen to like ARM in this channel, but it's not special in any way in an Ubuntu context.
[12:53] <amitk> nosse1: I haven't seen a bug report yet regarding this kernel crash (hint). If I do, I might be more able (and inclined) to help
[12:53] <nosse1> I think the job you guys devote to Ububtu ARM is awsome! It really simplifies the use of linux if we can use vanilla Ubuntu for a embedded target.
[12:54] <rcn-ee> hey amitk, any opinion on my mess of bug 541030 i was thinking about also insmod'ing the driver with a script in the initramfs if it was possible..
[12:54] <ubot4> Launchpad bug 541030 in linux-ti-omap (Ubuntu Lucid) (and 1 other project) "omap kernel musb/ehci ports not enabled on beagleboard (affects: 1) (heat: 12)" [Critical,Triaged] https://launchpad.net/bugs/541030
[12:55] <nosse1> amitk, thank you, I appreciate it. I will submit as we have something.  BTW: The lucid ti-omap kernel crashes on startup on the AM3517. Are you interested in a bugreport on that? (being a unsupported HW and all)
[12:55] <amitk> rcn-ee: working on the USB issue ATM (top of my list)
[12:56] <amitk> nosse1: yes, I'm interested in seeing what the crash is.
[12:56] <persia> nosse1: Just to be clear, Ubuntu isn't an embedded OS.  It's a general-purpose OS.  If you have very powerful hardware, you don't have to play embedded, but don't think you can reliably make it work with 128MB flash and 32MB RAM (which is fine for some OSs).
[12:57] <amitk> rcn-ee: are you saying in that bug (still reading through it) that compiling the modules in gets rid of the bug?
[12:57] <nosse1> persia, no problem. Our product will have 512M and 1G flash, so ubuntu-minimal with our app on top will fit perfectly
[12:58] <rcn-ee> Right now, just compiling in that original config change.. only the ehci port is active on startup..  Whereas you have to insmod one of the drivers to get the otg port working...
[12:59] <XorA> rcn-ee: OTG needs at least one gadget driver
[12:59] <rcn-ee> once i reverted the b585 commit, that config patch gives you an active ehci and otg port on startup..  I've currently seperated the b586 commit into a safe (doesn't break musb) and a what breaks it..
[13:00] <nosse1> What draws me to Ubuntu (over pure embedded linuxes, like OpenEmbedded) is the package maintenance and upgrade system. Having this, makes us focus solely on our app and we can consider the HW as a "general PC"
[13:00] <amitk> rcn-ee: you're testing this through a powered USB hub, I presume?
[13:01] <rcn-ee> correct... with a correct otg to usb connector...
[13:01] <rcn-ee> XorA, yeah i usually leave the ethernet gadget built in...
[13:02] <persia> nosse1: Then you're in the right place.  Just don't confuse it with real embedded stuff: there's all sorts of stuff installed that "wastes" space from that viewpoint.
[13:04] <rcn-ee> I'm going to spend some more time on it today, CONFIG_USB_MUSB_OTG=y is in the bad diff, but I've been using it fine on my own builds..  It's just the right combination of config options to get it to work...
[13:05] <amitk> rcn-ee: right, we need to fix the Kconfig options upstream DTRT
[13:09] <rcn-ee> yeah... more then likely, but as a note CONFIG_USB_MUSB_OTG=y does work in my 2.6.33.x mainline branches on rcn-ee.net..
[13:10] <nosse1>  /etc/fstab needs to be configured with the correct / source right? Because this is used in the initrd image to remount root, right?
[13:10] <persia> Right.
[13:40] <nosse1> Do you have a standard workflow (like update-initramfs) for making U-boot images from the kernels in /boot ?
[13:46] <nosse1> amitk, OK Now I've loaded the ti-omap kernel with the kernel crash. You want me to submit the full output?
[13:47] <amitk> nosse1: dmesg, cat /proc/cpuinfo output is appreciated. Please attach it to a launchpad bug
[13:47]  * persia recommends using `ubuntu-bug linux-tiomap`
[13:47] <nosse1> amitk, Can't give cpuinfo, as I cannot get so far to have a console.
[13:48]  * amitk would recommend that too, but suspects nosse1 isn't running the full rootfs yet
[13:48] <amitk> nosse1: ok
[13:50] <nosse1> Which project/package? This one: https://bugs.launchpad.net/ubuntu/+filebug/?no-redirect
[13:52] <amitk> nosse1: file it against linux-ti-omap
[13:52] <persia> https://launchpad.net/ubuntu/+source/linux-ti-omap/+filebug/?no-redirect
[13:55] <nosse1> sorry for being such a newbie here, but I understand you want me to put tags on it?
[13:55] <persia> "armel" is probably enough to start.
[13:55] <persia> But it's somewhat superfluous for that package, as it doesn't work on any other architecture :)
[14:03] <nosse1> Does this bug 556482 contain the information you need. I'm humble to comments...
[14:03] <ubot4> Launchpad bug 556482 in linux-ti-omap (Ubuntu) "kernel crash when booting on AM3517-EVM (affects: 1)" [Undecided,New] https://launchpad.net/bugs/556482
[14:04] <persia> nosse1: Please also attach /proc/cpuinfo and dmesg
[14:05] <nosse1> persia, for a system that I can't boot?
[14:05] <hrw> nosse1: kernel outputs something during boot right?
[14:06] <persia> The output was attached.
[14:06] <hrw> nosse1: and /proc/cpuinfo from working kernel
[14:06] <hrw> ah, did not yet checed
[14:06] <persia> dmesg from working kernel may also be interesting (but make it clear that this is not the regular kernel), just as a reference.
[14:06] <nosse1> this is the initial bringup of this HW, unless you guys have used the AM3517 evm before
[14:06] <hrw> nosse1: remove audio from kernel and boot
[14:08] <nosse1> Yeah, I have done that in my own custom compiles. I still can't boot for some other reason. Point is, I assumed you were interested in feeback regarding the vanilla kernels
[14:08] <persia> Absolutely, but the more information you can provide, the better a chance that the issue can be fixed.
[14:09] <nosse1> Will do. Except the kernel will not be compiled natively (yet) since I don't have a running system. I have to crosscompile to speed things up until then
[14:10] <hrw> nosse1: according to kernel output problem is in am3517 audio drivers
[14:11] <nosse1> Yes, that is what I also figured
[14:11] <amitk> nosse1: as hrw stated, could you recompile the kernel with sound disabled, it looks like a sound driver crash
[14:12] <amitk> [  675.150604] AIC23 Audio Codec 0.1
[14:12] <amitk> [  675.154052] Failed to add route LOUT->Line Out
[14:12] <amitk> [  675.158538] Unable to handle kernel NULL pointer dereference at virtual address 00000004
[14:15] <amitk> nosse1: but thanks for pointing out a problem in my own configs, I will now move sounds drivers to modules, they're not required for boot
[14:16] <nosse1> np. I'm looking forward to try the new kernel ;)
[14:25] <hrw> btw - can I download working kernel+rootfs for beagleboard somewhere?
[14:26] <amitk> hrw: http://cdimage.ubuntu.com/cdimage/ubuntu-netbook/ports/daily-live/current/
[14:26] <amitk> hrw: dd to an sd card and go!
[14:26] <hrw> gracias
[14:27] <persia> hrw: If it doesn't work in any way, please file lots of bugs: it *should* work.
[14:27] <persia> hrw: Also, we're currently preparing for the beta2 release: if you're up for participating in the test review process, /join #ubuntu-testing and folks will get you sorted.
[14:28] <hrw> persia: I will take care of resulting bugs in May. April is already booked for other projects
[14:29] <persia> hrw: Please file the reports, even if you don't fix them.  The idea is that if we don't know what is broken, we can't fix it :)
[14:29] <persia> (and the other idea is that we want to make sure the image called "Beta 2" is actually decent)
[14:30] <hrw> sure
[14:35] <amitk> ogra__: asac: any chance the beta2 images will enable serial port by default?
[14:36] <persia> amitk: I believe they don't currently, but that could be enabled if you think it's a beta-blocker.  Does the current kernel have all the right support?
[14:37] <persia> amitk: And don't you need a new kernel for beta2 anyway, for USB?
[14:38] <lrg> persia: I have that build machine info for David M. Can you send me his email details, I  didn't get his card in Nice
[14:39] <amitk> persia: there is nothing lacking on the kernel side for serial port support, it is missing in userspace (kernel cmdline + //etc/init).
[14:39] <hrw> lrg: you here too?
[14:39]  * hrw see more and more OE developers aroung ubuntu/arm
[14:40] <lrg> hrw: I'm everywhere :)
[14:40] <amitk> persia: It severely hampers working with the board for sure
[14:40] <persia> amitk: So, if that gets turned on, doesn't it break something with plymouth?
[14:40] <amitk> persia: if it does, I haven't heard of it.
[14:40] <hrw> persia: developer board should always respond on serial port with getty
[14:41] <hrw> thats why my desktop has 7 serial ports
[14:41] <persia> hrw: Yes, but 1) that's different than console, and 2) the images Ubuntu produces are end-user images (which can be used for development).
[14:42] <amitk> persia: I've always disagreed with point 2 being a reason to disable serial console (even on FSL and MVL)
[14:43] <persia> amitk: Well, how about other architectures?
[14:43] <persia> I'm not opposed to serial consoles, but I don't see any reason for ARM to be special, vs. e.g. PPC or amd64.
[14:45] <amitk> persia: ARM is special in the sense that we're working mostly with dev boards and vendor kernels that are still WIP. So debugability (sp?) is a must.
[14:50] <nosse1> For you guys running u-boot, how do you update the images from the stock kernels? Do you mkimage manually, or is there some tool/script available which triggers on update-initramfs?
[15:48] <amitk> nosse1: http://people.canonical.com/~amitk/ti/linux-image-2.6.33-500-omap_2.6.33-500.4_armel.deb is a kernel w/o sound compiled-in. See if it works better for you.
[15:55] <nosse1> amitk, Thanks. I got this:
[15:55] <nosse1> dpkg: error processing linux-image-2.6.33-500-omap_2.6.33-500.4_armel.deb (--install):
[15:55] <nosse1>  short read in buffer_copy (backend dpkg-deb during `./lib/modules/2.6.33-500-omap/kernel/net/econet/econet.ko')
[15:56] <hrw> nosse1: refetch as you have broken deb file
[15:56] <nosse1> I can be a bug in qemu which I use to deploy the deb
[15:58]  * nosse1 refetching
[15:58] <hrw> nosse1: manually extract deb file
[15:59] <nosse1> The deb download no2 is different from first. Either amitk rebuilt the deb or my download was faulty the first time
[16:03] <nosse1> amitk, Crashed at the same spot. I'm double checking to see if I am running the new kernel or not
[16:05]  * armin76 has better hardware than NCommander (still)
[16:11] <persia> armin76: Isn't that usually the case?  I would expect it to be a requirement for your distro of choice :)
[16:12] <hrw> 'your penis is larger then mine' talks again?
[16:14] <persia> !ohmy | hrw
[16:14] <ubot4> hrw: Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.
[16:14] <persia> But yes.
[16:15] <hrw> but how many of you has armv4t board with EP93xx cpu?
[16:15] <XorA> persia: made it back to tokyo then?
[16:15] <hrw> totally broken VFP unit, hardware decelaratted graphics...
[16:15] <persia> hrw: heh.  Don't think that can even run any Ubuntu.
[16:16] <persia> XorA: Yes, and smoothly.  I made the sensible choice of refusing the wheelchair at Narita, which got me through the airport ever so much faster :)
[16:16] <XorA> persia: yeah that guy wasnt the fastest helper in the world :-D
[16:16] <nosse1> amitk, the config file in the deb file you provided are exactly equal to the one the main repo. Hence the audio is still enabled
[16:17] <suihkulokki> hrw: EP93xx has maverick fpu, no vfp iirc ?
[16:17] <lrg> XorA, persia: heh, at least you guys were not left holding the baby ;)
[16:18] <XorA> lrg: you looked so comfortable with it as well :-D
[16:18] <hrw> suihkulokki: yes, anyway it still require set of patches to be usable
[16:20] <nosse1> amitk, I hope you get this. I need to leave for the evening
[16:20] <nosse1> See you later guys!
[16:23] <armin76> persia: no :(
[16:25] <persia> Oh well.  Sorry for the compilation dig.
[16:28]  * XorA suddenly remebers his beagle has two SD slots and gets a lot happier
[16:53] <ndechesne> hi, all. how can I get the exact version number of each package, without a running system? e.g. i want to know which version of gstreamer is in lucid. is there a tool/webpage i can use?
[16:55] <hrw> ndechesne: http://packages.ubuntu.com/PACKAGENAME
[16:56] <persia> Or use rmadison.  p.u.c is usually hours (and sometimes a day or so) out of date.
[16:56] <persia> `rmadison ${PACKAGE}`
[16:57] <persia> Alternately, https://launchpad.net/ubuntu/+source/${SRCPACKAGE} is always correct.
[17:04] <ndechesne> hrw, persia: thanks. is there a madison.cgi for armel anywhere?
[17:05] <persia> versions are architecture-independent.  Everything is uploaded as source, and compiled against all architectures permitted based on the Architecture: fields in debian/control.
[17:05] <persia> If there is skew, it's either vey temporary, or will be represented as a build failure at http://qa.ubuntuwire.com/ftbfs
[17:06] <persia> The reason rmadison doesn't actually report for armel is annoying and related to datacenter layout.
[17:06] <persia> (and fixable, but not by most folk)
[17:06] <ndechesne> persia: thx!
[18:00] <Martyn> OOF
[18:00] <Martyn> the UDS hotel is expeeeeensive
[18:00] <Martyn> but I just emailed Jorge and he said a group code was coming from the organizer
[18:01] <Martyn> The plane ticket is likewise going to cost a pretty penny
[18:02] <persia> Yeah.  *Always* book the hotel using the group code.
[18:03] <lrg> Martyn: hmm... how much are we talking about per night ?
[18:04] <persia> Really, don't trust the non-group-code numbers.
[18:05] <persia> I can remember one case where an entire hotel was block-rented and the individual room cost ended up being something like 25% of the nominal charge.
[18:05] <peterkirn2> hmm, picked up the rootfs from rcn-ee, but ... is there a convention for default userid / password on these images? (I had built mine from scratch, so set it myself!)
[18:06] <persia> peterkirn2: Try ubuntu/ubuntu or ubuntu/<empty>
[18:07] <peterkirn2> persia: nope. also tried ubuntu/passwd as I had seen that somewhere.
[18:07] <Martyn> Irg : 170 Euro for the cheapest room
[18:07] <Martyn> Irg : 240 Euro for a decent (but only mid-range) room
[18:08] <Martyn> Irg : You don't want to know where it goes from there
[18:08] <peterkirn2> persia: may just need to return to building my own rootfs ;) I still can't work out why my root permissions are borked on the one I created; can't seem to find a fix.
[18:08] <Martyn> as it is, the flight from Austin to Brussels is going to cost me ~700 Euro
[18:09]  * Martyn is unhappy with the lucid rootfs 
[18:09] <lrg> Martyn: I hope the group code is good. I have to buy with UK pounds atm and they are very weak :(
[18:09] <persia> peterkirn2: Dunno.  Try extracting one from one of the images, or ask rcn-ee
[18:09] <Martyn> I'm getting a strange error, and I can't remember for the life of me how to fix it --- procps terminated with error code 255
[18:10] <Martyn> Are there any known issues with lucid rootstock?
[18:10] <peterkirn2> persia: there's a way to extract uid / pwd from an existing rootfs?
[18:10] <persia> uid is easy: just mount it somewhere and check /etc/passed.
[18:10] <persia> passwd!
[18:11] <peterkirn2> ah, of course
[18:11] <persia> pwd is harder, but easy to set to nothing if you can mount the rootfs somewhere.
[18:11] <ogra> Martyn, only the qemu hang if you install bigger tasks and the rootstock GUI eating your CPU are currently on my plate
[18:11] <peterkirn2> persia: yeah, of course; I usually don't have rootfs lying around so hadn't occurred to me to think through how that'd be done. will do. :) at least then will know how this fs is working, which may reveal something about why karmic rootstock was causing trouble for me.
[18:12] <Martyn> Okay, I'll switch to debootstrap then
[18:12] <hrw> http://marcin.juszkiewicz.com.pl/2010/04/06/another-job-change/
[18:12] <Martyn> debootstrap –variant=minbase lucid rootfs.ubuntu ... right?
[18:12] <Martyn> then I can run the server task
[18:17] <ogra> Martyn, you want qemu-debootstrap
[18:18] <ogra> and --arch armel
[18:18] <persia> Well, depends on whether you're native or not, but often.
[18:18] <ogra> right, indeed, if you are on one of your speedy -a9 servers you even might run it natively :)
=== hrw is now known as hrw|gone
=== XorA is now known as XorA|gone
[18:33] <Martyn> ogra : Why?
[18:33] <Martyn> I'm native on a tegra2 now :)
[18:33] <ogra> pffft
[18:33] <persia> native debootstrap is definitely preferred
[18:33] <Martyn> and I have (undisclosed hardware) that's running at 1.6 GHz
[18:34] <persia> Cool!
[18:34] <Martyn> but weirdly outfitted as a tricore.
[18:34] <persia> What's wrong with tricore?
[18:34] <ogra> stop making us eager !
[18:34] <Martyn> it's strange, and has wierd knock-on effects with the strange amount of L2 cache
[18:34] <Martyn> but it's fast .. gods so far
[18:35] <Martyn> fast rather
[18:35] <Martyn> ogra : I'll bring at least ONE of these platforms to UDS
[18:35] <Martyn> although it will probably have to hide inside a box.
[18:36] <Martyn> Linux quark-a9 2.6.29-arm2-dirty #1 SMP PREEMPT Fri Mar 31 17:25:45 CDT 2010 armv7l GNU/Linux
[18:36] <Martyn> 2048 megs of memory installed on 'em too .. but only 667MHz .. :(
[18:37] <Martyn> I can't wait till I can slam in 4GB of 1033
[18:37] <persia> even 2048/667 makes a lovely server for lots of purposes.
[18:38] <DanaG> Martyn: tricore ARM?  Spiffy.
[18:38] <Martyn> DanaG : Yeah, but all our other platforms have either dual or quad core
[18:38] <Martyn> DanaG :This wierd tricore chip is the way it is, because the fourth core failed verification and was laser disabled
[18:38] <DanaG> hmm, my only piece of ARM hardware is my beagleboard.
[18:39] <Martyn> persia : Yes, it does.   We'll know if I can get lucid up and working correctly shortly.
[18:39] <DanaG> Are there any easily-available dual- or quad-core ARM thingies out there?
[18:39] <amitk> you'll probably have to break-in
[18:39] <Martyn> DanaG : the tegra2...
[18:43] <DanaG> hmm, just need to figure out where to get one.  seems to be easier said than done.
[18:44] <DanaG> er, "more easily"
[18:44] <persia> DanaG: My solution has been "wait".  So far, this got me a working laptop last fall, and I'm expecting to have a good server this fall.
[18:46] <DanaG> When I got my current EliteBook, I had to wait essentially from May until like September before the thing was available customized-to-order.
[18:46] <DanaG> But it's better to wait for something you really want, than to buy something you won't really like, "now".
[18:47] <persia> I guess.  I just went to the shop and got a Netwalker a couple weeks after they went on sale.  It's very much not customised-to-order, but it works.
[18:47] <DanaG> too bad tegra isn't available the same way the beagleboard is.
[18:47] <DanaG> I had to CTO my laptop, because I wanted 1920x1200 with ATI.  Prebuilt didn't offer that.
[18:48] <DanaG> hmm, netwalker... looks interesting.
[18:49] <DanaG> $479, if that's what it's supposed to be, looks too expensive for what I'd get.
[18:49] <persia> Nice little laptop.  Not much onboard storage, and would benefit from bluetooth or stereo audio, but...
[18:49] <persia> Yeah, well.  Pricing is different here :)
[18:51] <DanaG> mono audio... bleh.
[18:55] <persia> I guess.  I mostly wanted an update for my Zauri: it's a bit larger than I like, but nobody else is selling anything comparable right now.
[18:56] <DanaG> I mean, if you're going to have a mono speaker... at least have it centered. =þ
[18:58] <persia> I just turned off sound :)
=== Tscheesy is now known as Blizzz2
=== Blizzz2 is now known as Tscheesy
[19:18] <Martyn> which package includes the stuff needed for tasksel's dialog?
[19:18] <Martyn> I looked for 'dialog' and didn't find it
[19:24] <Martyn> nevermind :)  I forgot to add 'universe'
[19:38] <Martyn> Drat ...
[19:38] <Martyn> upstart is really not acting nicely
[19:39] <armin76> bad upstart :)
[19:39] <Martyn> if do a debootstrap, there still just isn't enough in there to get to a console
[19:39] <Martyn> http://blog.bodhizazen.net/linux/lxc-configure-ubuntu-lucid-containers/
[19:39] <Martyn> O
[19:39] <Martyn> I'm following this recipe, somewhat modified .. to build rootfs
[19:40] <Martyn> init: upstart pre-start process (544) terminated with status 32
[19:40] <persia> If you skip the --variant bit it ought be fine.
[19:47] <Martyn> persia : Wait, are you saying that using minbase is no longer desireable?
[19:47] <persia> No.
[19:48] <persia> I'm saying that I don't believe variants other than buildd to be well-tested in Ubuntu, and I don't expect the buildd variant to be sufficient to boot a working system.
[19:48] <persia> I may be mistaken.
[19:51] <Martyn> Well, I'll try again without a variant
[19:51] <Martyn> and see if the resulting system is bootable
[19:54] <persia> Good luck.
[19:54] <persia> You might also try playing with vm-builder, which is designed to generate (native) target filesystems for applicances.  Pulling the filesystem out later is left as an expercise for the developer.
[20:29] <DanaG> http://www.wired.com/gadgetlab/2010/01/hands-on-skylight/
[20:29] <DanaG> now... when can we  BUY  one of these?
[21:57]  * prpplague wonders if davidm actually drops in the channel
[22:06] <JamieBennett> prpplague: he does :)
=== bjf is now known as bjf-afk