=== 14WABV4VR is now known as sunnydrake === tmzt_ is now known as tmzt === StevenK is now known as wgrant_ === wgrant_ is now known as StevenK === Jack87|Away is now known as Jack87 === Jack87 is now known as Jack87|Away === doko__ is now known as doko === asac_ is now known as asac === XorA|gone is now known as XorA [11:00] has anyone tried running libvirt on oneiric on the arm? [11:02] zul, did it build yet ? [11:02] yesterday it failed [11:03] i tried a local build but that failed even earlier [11:03] ogra_: im using an older version i think 0.9.2-4ubuntu7 [11:03] right, with yesterdays upload it FTBFS [11:15] ogra_: really? grrr [11:54] ogra_, hey, is there any minimal (ie. less than 200mb headless) image for natty? [11:54] * robclark looking for link for recovering busybox user [11:55] sure wiki.ubuntu.com/ARM/OMAP [11:55] thx [11:56] ogra_, but headless img is still quite large (by busybox standards).. [11:56] I thought there was something smaller.. [11:57] there is ubuntu-core in oneiric, thats just 35M [11:57] the natty ones are around 200M [11:57] ok.. then I guess oneiric it is [11:58] note though, ubuntu-core is just a rootfs [11:58] http://cdimage.ubuntu.com/ubuntu-core/releases/oneiric/alpha-3/ [11:58] and give feedback to infinity, its his baby :) [11:59] that is fine.. it is for a kernel developer [11:59] well, there is no user creation or system configuration at all, you need to do all of it manually [12:00] I think that is fine for someone coming from busybox ;-) [12:00] k [12:00] :) [12:00] hmm, don't see the ubuntu-core img.. and looks like alpha-2 is gone.. [12:00] just use the link above [12:01] http://cdimage.ubuntu.com/ubuntu-core/releases/oneiric/alpha-3/ [12:01] its not an image, its a tarball [12:01] yeah, yeah.. but either I'm blind or there still isn't anything smaller.. [12:01] hmm, ok.. [12:01] * ogra_ sees 35M next to the tarball file [12:02] hmm.. I search for "tar" and don't even find any match on the page [12:02] ahh, wait, wrong url [12:02] using the same link ? [12:02] aha [12:03] nm, my bad [12:03] robclark: have you tried the linaro nano images? [12:04] hmm, no [12:04] amitk, linaro nano images, one can still 'sudo apt-get install'? [12:06] robclark: yes [12:06] robclark: they are stripped down headless [12:06] robclark: https://wiki.linaro.org/Cycles/1108/Release#Developers_and_Community_Builds [12:06] ok, cool.. [12:08] ogra_: it would be interesting to know the ubuntu-core and nano and combine them [12:08] ogra_: *know the difference between === asac_ is now known as asac [13:04] hello, i've a question. i don't really need gdm and gnome on my pandaboard, so i would like to be able to run startx as a user on boot, instead of getting gdm start. how can i do that? [13:12] ogra_: hey. what's the ubuntu core image exactly? [13:16] LPhas, yes you can [13:23] ndec, it is not an image, it is close to what you would get by using debootstrap to create a chroot [13:23] just a tarred up chroot without any setup or configuration [13:24] how is it built? [13:24] using live-build like all other images [13:25] which packages are installed? ubuntu-minimal? [13:25] less i think, aks infinity or look at the manifest files of the daily [13:26] ndec: More or less debootstrap --minbase ... Which is a LOT less than ubuntu-minimal. [13:26] ndec: And I suspect I'll strip it down further at some point. [13:26] ok. what's the purpose of this image, well tarball [13:27] and what's the uncompressed size on SD? [13:27] It's for people to build their own random systems around. Tiny rootfses as a starting point is a pretty common use case in the (pseudo-)embedded space. [13:27] Honestly, it's something I except most people to ignore. ;) [13:27] yeah [13:27] But it can be handy at times (I installed my ac100 with it). [13:28] way to much effort to actually make it proper [13:28] Uncompressed size right now is 110M or so? I think? [13:28] wow, that big ? [13:28] ogra_: Well, making it "work" it just a kernel, a bootloader, and setting up /etc/{hosts,resolv.conf} [13:28] But making it useful is a bit more effort for most. :P [13:29] creating a user, making sure tz and locale are correct etc [13:29] * infinity nods. [13:29] loopback networking too ... [13:29] etc [13:29] * ogra_ always forgets half of it unless he has to implement it somewhere [13:30] siji, thank you... how? [13:31] i am one of these guys that make custom derived ubuntu images , hence my interest ;-) [13:34] ndec, well, better use the server image as a base or so [13:35] ogra_: Oh, and it's about 96M now, not 110. Apparently. [13:35] i am just wanted to make sure i know what it is.. for now, i have been quite happy with the regular desktop images. as i told you in the past we 'chroot' them to install our packages so that it becomes a custom pre installed image. and it's been enough for now [13:35] yeah, i think i remember 80 from some years ago using minbase ... [13:35] And the "which image to use" question depends on what you intend to do with it. If you want it to have an installer, core's probably not for you. [13:35] i guess if we dropped all the drm libs it will be around that again [13:36] core is for people who start from scratch, build a "perfect" gold image of exactly what they want, and then burn it to each device on its way out the door. [13:36] That sort of use case. [13:37] Like I said, pretty common in the (semi-)embedded space, pretty rare in the rest of the world these days. [13:39] * ogra_ builds the first ac100 rootfs [13:40] lets see if infinity's tarball handling in live-buildd works :) [13:40] *live-build [13:41] Define "works". It's pretty sketchy. ;) [13:42] infinity: are you talking to the linaro team where they are doing nano images? [13:42] amitk: Oddly enough, "nano" images never came up during the week I was actually in the same room with them. [13:43] infinity: that is why irc is so much better ;) [13:44] infinity, well, i just run "ARCHES=armel+ac100 buildlive ubuntu daily-preinstalled" on antimony ... if a vmlinuz, rootfs and initrd come out at the rearend i call that "works" :) [13:45] ogra_: That doesn't sound like it would produce a tarball. [13:46] infinity, why not? for ac100 the filesystem is defined as plain [13:46] it should just dtrt if i didnt misunderstand the code [13:47] Well, assuming buildlive has any concept of any of that. [13:47] and it didnt fail yet [13:47] i added it to buildlive, yes [13:48] It might just work, then. I'll be pleasantly surprised. :) [13:48] (if a build survives 30min it usually finishes ... i'm 20min in) [13:48] Oh, it'll finish on the buildd side, no issues. I'm more curious about what happens after that. [13:49] nothing yet [13:49] i only call buildlive atm, debian-cd doesnt have any post processing code yet [13:49] But I guess I did hook support for plain into find/download-live-filesystem and such, so it should probably DTRT. [13:49] i sould only find a tarball, initrd and kernel in the right dir under /srv/cdimage ... [13:50] if it doesnt i'll fix it (thats why i'm doing this testbuild atm) [13:50] Heh. [13:52] the live-build documentation is nearly unusable imho [13:52] There's documentation? [13:52] man live-build or live-build -h doesnt get you any info [13:52] (Yeah, it's awful) [13:52] please any idea on how to execute startx as a user on boot? [13:52] only the sub-script manpages will [13:52] LPhas: You mean manually? [13:53] no [13:53] use a display manager and configure autologin ... [13:53] automatically [13:53] is there a way, given a node in /dev, to lookup more information about that device? [13:53] ogra_, why should i use a display manager? O_O [13:53] because you want x to function properly :) [13:53] i.e. some function F('/dev/foo') that gives info such as: that's a usb device, or that's a tty [13:53] Because DMs do autologin already. [13:54] basically i want to do what with the old good init i do with [13:54] x:5:once:/bin/su - -- PREFERRED_USER -l -c '/usr/bin/startx /dev/null 2>&1' [13:54] and also care for setting up the envioronment [13:54] LPhas, so just do the same with upstart then [13:54] i can't understand upstart [13:54] i don't know bash [13:54] LPhas, if you are using ubuntu [13:55] LPhas: /etc/init/tty*.conf ... Change one to do what you want instead of spawn getty. [13:55] you can do autologin by adding exec /sbin/mingetty --autologin exnxt tty1 --Only for Console AutoLogin [13:56] infinity, let's try [13:56] "exnxt-->username" [13:57] siji, this look to be console autologin [13:58] LPhas, just use what you used before for startx [13:58] exec bin/su - -- PREFERRED_USER -l -c '/usr/bin/startx [13:58] err [13:58] exec /bin/su - -- PREFERRED_USER -l -c '/usr/bin/startx [13:58] that should just work [13:59] though i dont think infinity is right, you cant use the tty.conf scripts, they start on the wrong event so you might miss bots in the system [13:59] s/bots/bits/ [13:59] ogra_: gdm starts before tty* in our usual setup, it should be fine. [14:00] ogra_: (Try it sometime, boot your laptop and when GDM comes up, hit the consoles, getty's still not running) [14:00] start on (filesystem [14:00] and started dbus [14:00] and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1 [14:00] or stopped udevtrigger)) [14:00] stop on runlevel [016] [14:00] emits starting-dm [14:00] you will likely need all that [14:00] especially the emits [14:00] since other scripts look for it [14:01] ogra_, you mean modifying tty*.conf is not the right method [14:01] i mean that tty.conf likely has the wrong events [14:01] ok [14:01] here am doing some experiments on the same [14:02] None of the DM or session events should matter if your goal is to have a single X. [14:02] Trying to run XBMC in autostart [14:02] well, the above snippet is actually from a display manager .conf file [14:02] If you have other services listening for those events, they'll fail regardless. :P [14:02] ogra_: Yes, I know, but "startx" isn't a DM. [14:02] ogra_: And it doesn't actually provide session or dm services. [14:03] * infinity shrugs. [14:03] thats why you need the "started dbus" event [14:03] Only if you use dbus. [14:03] might be that you have a started dbus anyway by reacing runlevel2 [14:03] (He was saying he was going GNOME-free and the whole nine yards) [14:03] which nearly all desktops do today [14:03] oh, ok [14:04] if there is no desktop, dbus might not matter [14:04] Still, as I said, our current tty stuff (that just runs on [23]) starts well after our DMs do, so... [14:04] It's probably fine. :) [14:04] but if you use any app that needs a session bus you are screwed [14:04] ogra_, it seems like my prblm is also same [14:05] i have made autologin by modifying tty1.conf [14:05] then in my DM (xfce) created a *.desktop file for autostart XBMC [14:06] and XBMC starts working but, while I pressed any keys in keyboard the application is hanging [14:06] ogra_: You lose. [14:06] The following packages have unmet dependencies: ubuntuone-client-gnome : Depends: ubuntuone-client (= 1.7.0-0ubuntu2) but 1.7.1-0ubuntu1 is to be installed unity : Depends: unity-common (= 4.6.0-0ubuntu2) but 4.6.0-0ubuntu4 is to be installed [14:06] but mouse is working fine [14:06] infinity, i dont ! i have a logfile now !!! :) [14:06] ogra_: Heh. [14:08] BAH !!! [14:08] * ogra_ curses the archive being totally out of sync [14:08] no way to build test images with that ... grmbl [14:09] ubuntu-one ... and unity are both broken [14:09] sigh [14:10] They both build quickly enough. [14:10] Or are they FTBFS? [14:10] * infinity looks. [14:11] i dont think they are [14:11] unity was just uploaded today ... arch all should already be ready ... any is missing as usual [14:11] unity is. :/ [14:11] sigh [14:11] so no way for me to make FF with ac100 [14:11] Oh, because of libnux skew. [14:11] FFS. [14:12] yeah, as usual [14:12] On armel and PPC. [14:12] not sure whats up with ubuntuone [14:12] And boost... [14:12] it already caused failed images last night [14:12] is there a way to build server without preinstalled pool ? [14:13] * ogra_ ponders to move on with server images to get around that ... but i dont want to waste time on a 300MB pool [14:13] Not without editing auto/config currently. [14:13] hmm, k [14:13] Not sure that's a feature I care to add, since the only time you'd want that is when testing locally... [14:13] And for local testing, you can edit the config. :P [14:14] oh, i actually wonder ... [14:14] ---what happens if i use ubuntu-core as a flavour [14:14] would i still get a kernel/initrd with the tarball ? [14:14] * ogra_ tries for laughs [14:15] lets see if i kill antimony with that :P [14:15] You really won't. [14:15] Get kernels, I mean. [14:15] Actually... You might. [14:15] why ? depends if the subarch code overrides your plain code [14:15] Since core defines the no kernel business before the subarches happen. [14:15] yeah [14:15] i was hoping so [14:16] what does -core end up with for root ? [14:16] locked or just no passwd ? [14:16] No password. [14:16] I think. [14:16] like debian then ? [14:16] To be fair, I'm not positive. [14:16] because i think that is modified in ubuntu [14:16] Actually, it's probably just locked out of the box. [14:16] so if you dont override that default it will be locked [14:17] I dunno, I use it as a chroot, what's a password? :) [14:17] heh [14:17] (And it's meaningless as an installation image too, since part of installation is creating a user and/or setting a password) [14:17] So, yeah. Probably locked, but never checked. [14:18] I wonder what "--linux-packages=none --linux-flavours=ac100" will do to live-build's tiny brain. [14:19] Cause that's what you're going to end up with. [14:19] am i ? [14:19] Should do. [14:19] Plus explcitely installing the packages anyway. [14:19] So. [14:19] The tarball will be right. [14:19] I'm just curious how it will handle those two options. [14:19] We'll find out. [14:19] well, the subarch code uses add_package [14:19] For science! [14:20] Yeah, subarch uses add_package, which gets the files on disk. But then later, you get --linux-flavours=$FLAVOUR if $FLAVOUR is set. [14:20] For core, that's normally none, but it got set to SUBARCH. [14:20] But core also set --linux-packages to none to work around some other misfeature. [14:20] And I'm too lazy to trace and see what happens when those two conflict. :) [14:20] * ogra_ wants livecd.sh back ! [14:21] Yeah, me too. [14:21] silly complex crap [14:21] I can't help but feel like we've mostly reimplemented livecd-rootfs in auto/{config,build}, and we're just using live-build as a super complex debootstrap wrapper. :/ [14:21] But whatever. [14:22] thats what we do, yeah [14:22] Maybe we'll move more and more into the core functionality and work around fewer and fewer misfeatures over time and learn to love it. [14:22] i think that was colins initial plan [14:22] His plan was to learn to love it? :) [14:23] lol [14:24] no, to move livecd-rootfs into live-build over time [14:30] are there any enviroment differences between lauching a program with Alt-F2 (run program) and starting a gnome-terminal and launching from it? [14:34] bug 823971 [14:34] Launchpad bug 823971 in ac100 "Enhancement: Suggestion to use jffs2 Filesystem" [Wishlist,New] https://launchpad.net/bugs/823971 [14:37] ogra_: Oh, the ubuntuone-client-gnome thing isn't arm arcive skew. [14:38] ogra_: The ubuntuone kids just completely removed client-gnome. :P [14:38] ogra_: So, time for some seed updates. [14:38] s/arcive/archive/ [14:38] Or... [14:38] - Removed ubuntuone-client-gnome deps and binary packaging, as it was [14:38] moved out to separate project upstream. [14:38] Maybe not time for seed updates, maybe time to go hunting through the NEW queue... [14:39] * infinity hunts. [14:39] why the heck dont theys notify anyone ? [14:39] sigh [14:40] And I see no new sources... [14:40] So, we just have broken image builds. [14:40] Yay. [14:42] you shoudl put yourself in the notification list on cdimage :P [14:43] sycamore.buildd finished at Wed Aug 10 14:42:05 UTC 2011 (failed) [14:44] *sniff* [14:44] (that was core) [14:45] hmm, i dont get the prompt back [14:49] infinity, heh, so it finishesd and i see it installing abootimg, linux-ac100 and friends ... but it fails with "ls: cannot access vmlinu?-*: no such file or directory" [14:50] so i guess it wipes /boot somewhere [14:52] hmm [14:52] * ogra_ wonders if running find on /srv/cdimage.ubuntu.com/scratch/ was a bad idea ... runs since 10min now [15:01] hmm [15:02] i dont really see where it removes vmlinuz [15:06] ah [15:06] got it [15:06] hmm [15:06] so --linux-flavours=none doesnt seem to be set, else it wouldnt move to the ls that fails [15:08] oh [15:08] KVERS="$( (cd "binary/$INITFS"; ls vmlinu?-*) | sed -n "s/^vmlinu.-\$[^-]*-[^-]*-$FLAVOUR\$$/\\1/p" )" [15:09] do i misread that line or does it actually expect /vmlinuz-$vers-$flavour instead of /boot/vmlinuz-.... [15:13] ogra_: No, cause INITFS should be boot. [15:13] oh, ok [15:13] Oh, depending on what LB_INITRAMFS is set to... [15:14] Which I'm not sure about for core, since it has none, so I probably didn't follow that codepath. [15:14] ah, that might not be set correctly given i do something weird :) [15:14] What, with core not actually requiring a kernel at all. [15:14] well, i see it being generated in the log [15:14] so /boot should have vmlinuz and initrd files [15:15] it just seems like lb doesnt know about that :) [15:15] Right, but INITFS is set based on LB_INITRAMFS and lord knows what that's set to. [15:15] heh [15:16] well, its sad to see it getting that far and then fail [15:16] its really in its very last stages there [15:16] Oh, wait, no. [15:16] *scratch head* [15:17] INITFS is boot for core, that's fine. [15:17] But... [15:17] That's not the boot you think it is. [15:17] well, indeed i want the boot where linux-image unpacked vmlinuz to :) [15:18] * infinity tries to sort out where these kenrels get copied around... [15:18] I suspect it's just live-build not copying kernels out because of the linux-*=whatever confusion. [15:18] So, ultimately... Don't use core for this. :P [15:19] yeah [15:19] Or test locally with a hacked-up auto/config [15:19] but we dont have headless either anymore [15:19] hmm, or do we [15:19] * ogra_ looks [15:19] We don't. [15:19] But testing this on the buildds seems silly anyway. [15:19] You get much better turnaround testing locally on x86, then doing one final local test on arm. [15:20] Well, assuming you have a reasonably close or local mirror.. [15:20] i need to know the structure of the dump the buildd gets me to move on [15:20] thats all i'm after atm [15:20] and thats why i do it on the buildd, i surely wont run a local debian-cd to do debian-cd development for the post-boot scripts [15:20] In theory, it should look the same as a mix of core and live. [15:21] That is, the rootfs will look like cores output, but the kernels should look the same as what live's doing. [15:21] i dont need core, i just tried it because desktop is blocking me atm [15:21] * infinity nods. [15:21] i will do server, that just takes longer [15:21] but should get me building images and accurate output files [15:22] * infinity spots a thinko in his auto/build ... [15:22] Or, rather, a place where I have a (correct) hardcoded value that should probably be a variable, to match everything else. [15:22] But harmless. [15:23] * ogra_ fires off an ac100 server build [15:25] EEEKK !!!!!!!!! [15:25] That's not a good sound. [15:25] building ubuntu-server gets me a germinat traceback in the log !!!! [15:26] I had considered making redirecting the germinate call, but I figure it might be handy for debugging some day. [15:26] s/making // [15:26] well, you need to proceed the seed somehow to get the ship seed, no ? [15:26] The logs aren't meant to be pretty anyway. :P [15:27] Well, yes. We need to run germinate. [15:27] i dont care about the logs, my build dies after about 10sec with germinate failing [15:27] Err, really? [15:27] giving me a key error [15:27] 'usb-langsupport' [15:27] Local, or on a buildd? [15:27] take a look at sycamores logs [15:27] ubuntu-server-ac100 [15:29] Curious. Last night's server-omap4 ran fine. [15:29] yeah [15:29] seeds might have changed today [15:29] A local germinate run is just as broken, though. [15:30] So, someone just broke the seeds, I guess. [15:30] key error smells like it [15:30] Or. What? [15:30] * infinity blinks. [15:31] ogra_: i think i asked you already... but i forgot ;-) when using unity2D which WM is used? metacity? [15:31] yep [15:32] thx [15:32] Something on lillypilly just went very pear-shaped. [15:32] you broke it ! [15:32] davidm: hi there. any news on the global availability of ARM PPA [15:32] Or I can't type. [15:32] There, that's better. [15:32] Yes, broken seeds. [15:33] ndec, none yet, IS is working on intergrating the first builder [15:33] yep [15:33] alison broke them [15:37] ogra_: Yeah, I see the commit that's broken, but it's not immediately obvious to me what broke it. :P [15:37] ogra_: You found the issue? [15:38] nope, i pinged colin, i dont really know about all the inheritance stuff [15:38] it seems ot be a completely new seed [15:39] ogra_: Do we still need the mem= lines on panda? I haven't seen any issues lately, and the netinstall doesn't add them. [15:39] It is. [15:39] GrueMaster, we need them for ducati (multimedia) [15:39] so we still need them on the desktop [15:39] server, not so much [15:39] Ah. [15:40] ducati requires a memory hole at the right place iirc (we should check if thats still at the right position nowadays though) [15:42] so you don't want to use the server image for transcoding video? [15:42] if people use it like that they should adjust boot.script :) [15:43] If there's a piece of hardware on this that requires the memory hole, we should have it there regardless of installation type... [15:43] we should update boot.script in the ducati package as postinst and force a flash-kernel and reboot ;-) [15:43] (We should probably just have the kernel doing it by default) [15:44] infinity: it's a s/w limitation, not h/w [15:44] ndec: How so? [15:44] we reserve come carve out memory for a special h/w accelerator, the physical address reserved in hard coded in the kernel... [15:45] None of that sounds like a software limitation to me... [15:46] well, the h/w does not require the memory hole. it's our s/w design that requires it [15:46] As in, we could be talking to it directly somehow, instead of mmapping it in system RAm? [15:47] I would have assumed this is just how it's designed to be done. [15:47] Either way, my point was that if the hardware's there, and if that addressing technique is our only way to talk to it, we should just have the hole on by default and be done with it. [15:48] i would tend to agree... the counter argument is that you are wasting 50Mb of RAM for the server image, and that might be important too... [15:49] * infinity shrugs. [15:49] omap4 isn't a serious server platform anyway. Losing 50MB to make sure all the hardware is doing the right thing from userspace's POV feels right to me. [15:50] And, as you point out, omap4 as a media server is probably a more likely use-case than as an HPC cluster. [15:50] Just a guess. ;) [15:51] i personally don't care too much (now) about the omap4 server image anyways ;-) [15:51] Well, it's just a proof-of-concept anyway. [15:51] But I could see repurposing my Panda as a set-top-box once I get "real" ARM server kit in here for other server testing. [15:53] and guess what if you had installed the server image *without* the memory hole in bootargs, and convert it as set-top-box then video won't work because the hole is for the video accelerator! [15:54] pfft, details [15:55] But yes, I still think the boot args are a silly, messy, and error-prone waste of space. If the kernel knows where that hole should be, we should just have the kernel set it up by default. [15:55] And people could use a mem= line to override and undo that if they really know what they're doing and care deeply about the 50MB. [15:58] rsalveti: Thought on the above? [16:01] * rsalveti reading === XorA is now known as XorA|gone [16:37] I like that idea. We are limited to the amount of characters on the kernel cmdline, removing the two mem= lines helps considerably. [16:38] (my cmdline length issue is PXE boot netinstall w/ preseed mainly). [16:40] yeah [16:59] can we setup the memory map from the kernel? [17:10] ogra_: infinity: we've being using with the 50MB hole at natty even without any working multimedia modules ;-) [17:11] for me it feels ok to just remove it and use the whole 1gb for a server image [17:11] if someone would like to setup the ti ppa, it'll probably need to do it by hand anyway [17:11] rsalveti, well, the discussion was about moving the option as a default into the kernel instead of having a cmdline option for it [17:11] so we just document the changes at the boot.args and be ok with it [17:12] this feels wrong [17:12] as it's a software limitation [17:15]