[00:11] Let say package A depends on B. And B on C. Now including B as a dependency of A will install C also.. right? Or we have to add both B and C as a dependency. [00:16] Other than libraries which are automatically hanlded, dependencies can change. So while at the moment B would bring in C, it's best to assume that it might not always do so, and depend on both B and C === neeraj_ is now known as neeraj [00:19] neeraj: did you catch my message before you lost your connection? === xfaf is now known as zul === neeraj_ is now known as neeraj === dendrobates is now known as dendro-afk [03:01] slangasek, ping [03:01] robert_ancell: hithere [03:02] slangasek, hey, question about this vte include problem - what package is using it in this way. There seems to be an inconsistency in how "includedir" is defined [03:02] robert_ancell: both gir-repository and vinagre both FTBFS this way [03:04] slangasek, ok, looking into what they're doing - note that vinagre has it's pkg-config file set up the same way [03:08] any archive admins want to sync a security update? :) [03:10] slangasek, vinagre builds for me, and appears to have built fine in the archives - do you have a build log? === dendro-afk is now known as dendrobates [03:12] robert_ancell: hmm, didn't keep a log; don't even remember now for sure that I did build it, as opposed to inspecting the source visually. Will double check and get back to you in a bit [03:12] ok === steve|m1 is now known as steve|m [03:19] robert_ancell: ah; no, I didn't try to build vinagre, I just looked at the source to confirm that it expected "vte/vte.h" as a header rather than "vte-0.0/vte/vte.h" [03:19] robert_ancell: so it may just be gir-repository affected by ths === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [04:28] kirkland: beautiful blog post :) [07:32] Good morning [07:38] pitti: evening [07:51] good morning [07:55] good morning [07:56] hey dholbach [07:56] heya mvo === ara_ is now known as ara [08:09] mvo, good morning, we've found another culprit causing bug 614993. [08:09] Launchpad bug 614993 in xorg-server (Ubuntu) "10.04 -> 10.10 upgrade fails: pkgProblemResolver::Resolve generated breaks: xserver-xorg-video-v4l demoted to universe" [Critical,In progress] https://launchpad.net/bugs/614993 [08:09] mvo, xserver-xorg-video-radeonhd has been removed from maverick and is blocking the upgrade. [08:10] mvo, but that does'nt fix the pb for everybody and there is still another one. [08:11] thanks jibel, I look at it again [08:12] jibel: odd that it worked for me, but maybe I had the wrong set of package, I investigate [08:14] mvo, I'm able to reproduce the issue on a fresh 10.04.1 [08:15] mvo, but that doesn't fix it for bdmurray and another reporter. There is probably something left from a previous upgrade. [08:16] * mvo nods [08:22] didrocks: don't think so [08:50] dholbach> Just saw your post on Planet Ubuntu... So are the Launchpad daily builds a feature that allows anyone to request Launchpad to do daily builds from VCS without any manual intervention or setting up your own daemons? [08:50] lucidfox, yes, the code needs to live in Launchpad though (vcs imports) [08:51] Neat [08:51] https://help.launchpad.net/Packaging/SourceBuilds/ [08:51] Yes, saw that page :) [08:51] https://help.launchpad.net/Packaging/SourceBuilds/KnownLimitations is current breakage, but being worked on [08:51] * lucidfox goes to set up a daily build for Pinta [08:51] some of them will be fixed in the next LP release [09:00] mvo, that's xserver-xorg-video-dummy which is blocking the upgrade. it provides xserver-xorg-video-7 in maverick [09:00] jibel: yeah, I just found it out as well, I'm preparing a new xserver-xorg-core [09:01] jibel: it appears there is also -glamo [09:01] jibel: and (just to be on the safe side) I merged some from debian (vga, i81, imstt) that we probably don't need, but they will not hurt (and make the merge later easier) [09:02] mdke: thanks for the info :) [09:04] jibel: next thing is to debug apt so that its either more clever or gives at least better debug output [09:06] mvo, yep. apt.log gives no clue about what's wrong. [09:06] jibel: indeed :/ [09:06] jibel: thanks for keeping a eye on this bug! much appreciated [09:07] mvo, have a look at -glide too [09:09] jibel: aha, thanks. I missed that one (was in a amd64 chroot and that is i386 only afaics) [09:19] jibel: the updated breaks list http://paste.ubuntu.com/486211/ [09:40] if anybody has a tiny bit of time, can you branch lp:~dholbach/harvest/release-prep follow the instructions in the INSTALL file and play with it and see if there's anything glaringly broken? :-) [09:47] dholbach: having a poke [09:49] mvo, I think that -newport, -psb, tga, unichrome and -via are missing from that list. [09:51] dholbach: how long should the manage.py update take? [09:51] g: the first one takes a bit longer [09:51] jibel: thanks, that makes sense (modulo -via,that is just a transitional package) [09:51] oh, never mind, something happened :) [09:51] jibel: I add them now [09:52] jibel, -psb works? I thought it was unsuitable for use still. [10:07] tkamppeter: ping [10:08] persia, I don't know if it works but I can install it in hardy and then upgrade to a release where it's not available anymore. [10:09] jibel, Ah, OK. So a lucid thing, rather than a maverick thing? I believe it was available for hardy and jaunty (and not intrepid). [10:10] persia, yes. it was only available in hardy from what I've found. I haven't checked intrepid. [10:11] I'm fairly certain that if it was in intrepid, it was pointlessly broken, because Intel never released binaries that worked with that kernel and X. [10:11] For jaunty, it was only available in a PPA, but lots of folks with that hardware (which was common at the time) installed from there. [10:12] hi persia [10:13] Hey Kmos. Are you going to submit your "I'd like to be involved again" application soonish? I've been waiting. [10:13] (otherwise I'm supposed to ask you to leave the channel) [10:14] I was thinking I was still banned from talking here. but I'm stopping now [10:22] dholbach: that looks pretty neat! [10:25] dholbach: any particular bits you want tested? === diwic is now known as diwic_afk [10:39] g: just something glaringly obvious that breaks :) [10:39] g: so we can get it out there and deployed [10:39] if we have to fix small stuff later on, that's fine === amitk is now known as amitk-afk [10:58] dholbach: the only thing I'd say is for the bug numbers, include the bug titles [10:58] g: there's an open bug in harvest-data about that [10:58] thanks a lot for your review! [11:00] dholbach: ooh, here is one [11:00] Packages all unticked, Opportunities->sponsoring, Pidgin, a code branch has appeared, is that intentional? [11:01] ahhh actually I guess it is [11:01] yes [11:17] <\sh> hmm...who approves new uploads for bugfixes these days? [11:27] \sh, If you break freeze, ubuntu-release. if you don't, you. [11:28] (check if it's seeded first: generally apt-cache show works, because it ends up in tasks) [11:28] <\sh> persia, aehm...it's zend-framework, new bugfix release but new upstream version too...I uploaded it regarding the ffe guidlines...(all universe) [11:29] <\sh> and now it sits in "approval state" :) [11:29] dholbach, would be nice to have a way to display the opportunities not listed [11:29] dholbach, or to know why those nn are not listed [11:30] seb128, not listed because the opportunity lists are not chosen :) [11:30] or the filtering limited :) [11:31] \sh, Oh, that's the release team. They've just got the upload queue on manual. Check in #ubuntu-release if you need it fast, or wait a bit, and they'll likely push it. [11:31] <\sh> persia, thx :) [11:32] dholbach, would be nice to have a "select all opportunities" [11:33] dholbach, oh, it seems clicking on "selected" does that [11:33] seb128, yes, how do you think that could be made more obvious? [11:34] changing the label [11:34] "limit to selected" [11:34] or something which indicates it's a filter and not only a title for the sublist [11:34] and I guess the same for packagesets? [11:34] yes [11:35] I though those were just titles [11:35] I didn't get that you could click to toggle [11:35] dholbach, otherwise great work ;-) [11:36] seb128, bug 627340 [11:36] Launchpad bug 627340 in harvest "Change label of "selected" and "package sets" to "limit to…"" [Low,Triaged] https://launchpad.net/bugs/627340 [11:36] seb128, it was mostly Dylan McCall's doing [11:36] dholbach, danke [11:36] dholbach, is he on IRC? [11:37] dholbach, if not just tell him great work from me ;-) [11:38] seb128, sometimes - he's in west canada, so at the other end of the world :) [11:38] ;-) [11:38] dholbach, btw the fedora things is pretty useless [11:39] not your fault but they let all the old patches on their cvs it seems [11:39] so we get tons of things listed which are old and outdated and not used [11:39] yeah, I guess so === MacSlow is now known as MacSlow|lunch [11:40] I hope we can fix bug 581719 quickly [11:40] Launchpad bug 581719 in harvest "Speed up "making opportunities go away"" [Medium,Confirmed] https://launchpad.net/bugs/581719 [11:40] if it's a one click operation, I hope that'll make it easier for people to make use of that list [11:40] that would be nice [11:40] seb128: are you sure? if you look at something like Autoconf if it was that case you'd get a heap of them [11:41] I would not dislike having the label telling you about opportunities not listed doing the "list those" on click [11:42] seb128, I'm not sure I understand - can you rephrase? [11:42] dholbach: the thing that bugs me the most is the bit on the left [11:42] g: what's that? [11:42] G: http://cvs.fedoraproject.org/viewvc//devel/autoconf/ [11:42] G: ? [11:42] when scrolling it gets confusing w/ where I am on the page [11:42] dholbach: because it's not smooth/stuck at the top etc [11:43] the bouncing around is distracting [11:43] dholbach, I think I was asking for what "permalink" does [11:43] the wording is just not obvious [11:43] g: what's bouncing around? [11:43] dholbach: the left bit w/ the filtering options [11:43] dholbach, I'm browsing the list and just show that gnome-session has 11 opportunities [11:44] dholbach, I was wondering if there was a way to quickly see those without changing the filtering [11:44] seb128, so a 'reset filters' link? [11:44] ah ok [11:44] dholbach: if you say display all packages w/ fedora patches and scroll to the bottom it gets a little sickening [11:44] dholbach, no, just a "show me all the opportunities for that source" [11:44] seb128, do you think you can file a bug explaining how you'd like it to work? [11:44] dholbach, well "permalink" does it [11:44] ah ok [11:44] just not inline [11:44] but I can work with that [11:45] maybe you can file a bug for that, so it's inline? [11:45] ok [11:45] * dholbach hugs seb128 [11:45] …and submit a patch :-P [11:45] * seb128 hugs dholbach [11:45] lol [11:45] let's see [11:45] but lunch first [11:45] :) [11:45] dholbach: haha [11:45] g: it's not bouncing for me [11:45] dholbach, great work to Dylan and you in any case [11:45] seb128: can't check any other packages, looks like their CVS server has died [11:46] dholbach: might just be firefox for me [11:46] let me try my mac [11:46] seb128, maybe we can fix http://bugs.launchpad.net/fedora-patches-overview too [11:46] (it's what produces the fedora.csv list) === diwic_afk is now known as diwic [11:46] dholbach: I don't think it's broken [11:46] it's just that some maintainers don't delete unused patches [11:47] yeah, I guess [11:47] and it's not much use changing it now [11:47] dholbach, ;-) [11:47] because I can tell you, that Fedora are moving to git [11:47] I'm very glad you find it generally useful though [11:47] G: they are moving to git for how many years now? [11:47] seb128: they are serious this itme [11:47] *time [11:47] I'm waiting to see [11:48] I don't doubt they want to [11:48] they just seem to be busy with other things [11:48] seb128: their release engineering team are building the architecture for it now as I understand [11:48] ok [11:49] they might have the same issue on git though [11:49] and I know when I was involved in their Infra side (back in March) they were getting alive demo going [11:49] if the issue is due to people not doing a vcs delete [11:49] seb128: nah, as I recall they are going to exploded source [11:49] ok [11:49] let's wait then and see what they come with ;-) [11:49] seems interesting [11:49] OdyX, hi [11:50] seb128: well thats what I last heard anyway [11:53] last time I tried to look in Fedora's CVS, there was a note up saying that they'd already moved to git, and when I looked there it seemed to have unexploded source === amitk-afk is now known as amitk [12:12] slangasek: re: eucalyptus-udeb/avahi: the udeb uses avahi to detect existing components and provide default sane "next" installation choices. === asac_ is now known as asac === xfaf is now known as zul === thekorn_ is now known as thekorn === MacSlow|lunch is now known as MacSlow [13:24] OdyX, hi [13:29] tkamppeter: hi [13:46] hello [13:47] Im having a problem in ANDOID lnux kernel driver [13:47] can someone help me? [13:47] I want to READ a file in a kernel driver. [13:47] is there some set of APIs available. [13:49] We don't really do much android stuff here. Are you sure there isn't a more relevant channel? [13:49] android person dont know much about Linux-C [13:49] so i think you are most suitable to help me [13:50] can we read file in linux kernel? [13:50] mehranhu: sys_read() is not really supposed to be used from inside the kernel. If you are using it you're doing something wrong [13:51] what should i use? [13:52] i didnt found any API over the internet === dholbach_ is now known as dholbach [13:56] mehranhu: you're not looking hard enough :) http://kernelnewbies.org/FAQ/WhyWritingFilesFromKernelIsBad , http://lkml.indiana.edu/hypermail/linux/kernel/0502.0/1763.html, http://www.linuxjournal.com/article/8110 [14:42] micahg: did you ever get an AA to perfrom your security copy? [14:45] whats the rules of regressions between releases? [14:51] G, regressions are bad. File a bug. mark it a regression. The folks in #ubuntu-bugs and #ubuntu-testing likely have good pointers to wiki pages with procedures to handle that sort of thing (I forget them offhand) [14:51] persia: yeah, it's an already filed bug but feeling more and more like a regression [14:52] Yeah. Chat with the folks in #ubuntu-bugs, and make sure it has all the rights tags, status, etc. [14:53] ahhh I went into -testing, if I don't get anything there soon I'll pop into -bugs [14:53] persia: thanks though === amitk is now known as amitk-afk [15:27] jdstrand: no, bug 622900 [15:27] Launchpad bug 622900 in phpmyadmin (Ubuntu) "Please sync phpmyadmin 4:3.3.5.1-1 (universe) from Debian testing (main)" [Medium,Confirmed] https://launchpad.net/bugs/622900 [15:42] jdstrand: thanks [15:47] cking: do you have an amd64 system with UEFI to which you could attach a serial console or some other way to debug early code? [15:49] cjwatson, afraid not, I sent mine to manjo in TX [15:49] cjwatson, we could ask manjo to ship it to you, but it's a big dev box [15:50] probably not a plan [15:50] cjwatson: how do I find if I have UEFI? [15:50] cjwatson: I have a fairly recent ThinkPad X201, with current maverick amd64 on it === JanC_ is now known as JanC [15:50] "find out" [15:50] pitti, your bios should say UEFI v2.1 [15:51] pitti, check in /sys/firmware perchance [15:51] $ ls /sys/firmware/ [15:51] acpi memmap [15:51] cking,manjo: so, the current situation is as follows [15:51] cking: find /sys/firmware -iname '*efi*' [15:51] -> nothing [15:51] I guess that's a bad sign? [15:52] current amd64 (only) CDs contain a GRUB EFI build [15:52] I think sys firmware only has interrupts and such [15:52] micahg: sure [15:52] you can boot them using either BIOS or UEFI on a system capable of doing either [15:52] GRUB appears to boot the kernel fine; I used a test kernel cking gave me at the sprint which issues beeps right at the start of head_64.S [15:52] however, there is no output from the kernel [15:53] this is obviously a showstopper but it's not quite clear what's going on [15:53] cjwatson, is there a 64bit image I can get to on cdimage ? [15:54] the 'newreloc' branch was landed recently in GRUB upstream, and there's a possibility that it was due to the initramfs being loaded incorrectly in which case that might fix it [15:54] otherwise, it's hard to say [15:54] manjo: yes, any current amd64 one [15:54] ah yesw [15:54] newreloc was a pretty significant piece of work though [15:54] cjwatson, let me try down the latest x64 iso and give that a spin on my box [15:55] give me 30mts or so [15:55] right, it's always possible it was just this system, though I'm doubtful [15:56] I just got a new box from intel with latest build of uefi [15:56] I was wanting to install it anyways [15:57] but x64 image was not available for the last few builds [15:58] right, only landed recently. would have been longer ago except that there was a PATH issue in the daily builds [15:59] cjwatson, now downloading image ... will report back soon [15:59] thanks [16:00] I'll see if I can get to network-console [16:00] manjo, cjwatson: sorry, no trace of UEFI in BIOS or /sys [16:02] pitti: as I recally UEFI & 'BIOS' are mutually exclusive [16:02] i.e. you have one or the other [16:03] ok, s/BIOS/the ASCII GUI thing for configuring hardware/ :) [16:03] G: not true [16:03] G: I have a laptop just here --> that lets you select at boot time [16:04] cjwatson: between BIOS & UEFI? [16:04] G: I mean, it's probably a BIOS compatibility shim over the top of UEFI or something, but it lets you select either, yes [16:04] ahhh right yeah [16:04] yeah, I'd say it's a compatibility hack over the top [16:05] but functionally, that's all that's relevant [16:06] cjwatson: yeah, but for the most case, I am right is saying you can have one over the other at any particular time? [16:06] sure [16:06] *only one [16:07] personally I'm hoping UEFI catches on fast [16:10] G: I have mixed feelings [16:10] pitti, does any of your "boot" options in bios say uefi ? [16:11] manjo: no [16:11] pitti, if you have uefi bios it should give you an option in boot menu to switch between legacy and uefi === deryck is now known as deryck[lunch] [16:12] cjwatson: definately for servers, the 2TB boot partition thing has been a nightmare for ages, but for desktops, it will (hopefully) push the HDD makers away from the ugly 2TB+ hacks (like the WD Advanced Format drives) [16:13] * manjo wonders why we need 2TB on clients ... don't we have cloud for storage ? [16:13] manjo, reduced latency [16:14] manjo: haha, storage clouds make me laugh, especially when I'm sitting here w/ my 1.5Mbit down, 400kbps up link :) [16:17] manjo: but the other reason is that I create a ton of backups/shelve a heap of data to refer to later (not exactly important enough to warrant offsite backup but interesting enough to warrant something near-by) [16:33] cjwatson, I get a splash screen... [16:35] cking, what was the problem that cjwatson reported ? [16:36] cjwatson, I am going to proceed with the install ... looks like the CD booted fine (I need to double check that I booted in UEFI mode), UEFI CD/DVD was my 1st boot device and it looked like it recognized it as such === beuno is now known as beuno-lunch [16:37] manjo: do you get into the installer? [16:37] G: GPT is the best feature of UEFI [16:38] cjohnston, yes [16:38] manjo: coo [16:38] I am on allocate drive space etc... [16:38] but I see a problem there :) [16:38] let me know how it goes! my test machine doesn't get that far [16:38] select drive space : 360GGB ATA [16:38] below that [16:38] Ubuntu 0.0 B [16:39] what is that ? [16:39] cjwatson: yeah, hence why I want to see UEFI more common :) [16:41] manjo: I believe I've seen that bug on BIOS too [16:41] cjwatson, copying file now ... installing .. [16:41] manjo: I was expecting you to try server first :) [16:41] I can give desktop a try [16:41] cjwatson, was the problem on server iso not desktop ? [16:41] yeah [16:41] s**t [16:41] good to know that desktop seems to work though [16:42] that's useful in itself [16:42] ok will try the sever iso on another machine [16:42] do double-check that it booted in UEFI mode though [16:44] yep will do once its done installing [16:44] I need to reseed my server iso anyway [16:44] cjwatson, even if it booted cdrom in legacy mode I should be able to boot the HDD in UEFI mode correct ? [16:45] probably not since if it did that it would have put a BIOS version of grub there === sconklin1 is now known as sconklin [16:46] cjwatson, bad newsw [16:46] cjwatson, grub install failede [16:47] cjwatson, grub-efi package failed to install into /target/ [16:48] manjo: logs? [16:48] (with any luck I can try this too, in 1h45m or so) [16:54] cjwatson, http://kernel.ubuntu.com/~manjo/logs/logs.tgz [16:54] cjwatson, let me know if you need more info ... I will wait on reboot [16:56] superm1: Is the mythbuntu-common upload one that you need in for beta? [16:56] cjwatson, were you able to get the logs ? [16:57] yes [16:57] ScottK, yes ideally [16:58] OK. Let me check. [16:58] * manjo standing by [16:58] hm, I just queued up a mythbuntu build [16:58] oh well, you can just do another one later === deryck[lunch] is now known as deryck [17:02] manjo: ok, just a seed bug, fixed (though not in time for current beta builds) [17:02] can I work around ? [17:04] Keybuk: does ureadahead have some minimum blocking time on SSD as well? it seems the boot blocks on that on my system (http://people.canonical.com/~pitti/bootcharts/donald-maverick-20100805-1.png) [17:04] superm1: Accepted. [17:04] thanks [17:05] No problem. [17:06] manjo: uh, not sure [17:07] manjo: certainly not easily except by remastering the CD (which is in itself rather challenging) [17:08] actually, wait, the seed change was in ship-live! [17:08] not live - so that means the build in progress should pick it up [17:08] * manjo fingers crossed [17:08] pitti: not usually [17:08] cjwatson, ok will try the server cd to make sure it can make progress like desktop.. [17:08] I think it may read the pack before going into the background [17:09] but that's no time [17:09] cjwatson, you need anymore info from this box before I reboot ? [17:09] pitti: get a blktrace of that? [17:09] Keybuk: I'll read about it (never used that so far) [17:10] manjo: nope [17:10] manjo: actually [17:10] manjo: cat /proc/fb [17:10] Keybuk: but thanks (I mainly was curious about whether this is expected); so I'll put that on my todo list [17:10] manjo: and can you try ctrl-alt-f1 and see if you see anything on the console? [17:11] I am on f1 [17:11] proc/fb == 0 inteldrmfb [17:12] ok [17:12] there was noting on f1 when I switched [17:13] but there is now? what did you do? [17:13] ? [17:13] pitti: no, but it's hard to tell what's going on there === rbelem_ is now known as rbelem [17:13] I switched to f1 to copy logs etc to usb stick and put it up on kernel.ubuntu.com [17:13] manjo: do you mean that there was just a login prompt or something on ctrl-alt-f1 when you switched? [17:13] right [17:13] just a log in prompt [17:13] by "anything" I meant "not a blank screen" :-) [17:14] as in, is the console working [17:14] :) yeah console was working [17:14] pitti: for example, it could be that ureadahead is reading the things that modprobe already has loaded [17:14] heh I have gotten used to seeing a working console that Q confused me sorry [17:14] so it's null reads, that still cost syscall time [17:14] blktrace would reveal more detail [17:14] so it's possible that efifb isn't working, but that things get sorted out when inteldrmfb is loaded [17:15] in which case we'll need to bloat up the amd64 d-i initramfs some more [17:15] and figure out *why* efifb isn't working [17:15] or maybe there's some other difference between your machine and mine [17:17] I'm not entirely convinced that my initramfs is coming up [17:17] cjwatson, booting server now [17:18] cjwatson, server iso install in progress ... [17:18] that will suffer from the same problem at grub-efi, but cool, it works [17:19] that's an astonishing relief [17:19] now I need to figure out what's different about this box [17:21] cjwatson, yeah I guess its going to be the same fate... but I will let it make progress === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [17:34] cjwatson, ok hit the same spot ie bug [17:34] cjwatson, so you think the beta build for live server & desktop will pick up your fix ? [17:36] Just for a survey: what do you, developers, use for building a package? [17:39] cjwatson, I am 99.999% sure that I am booting UEFI mode, the 1st boot option on my boot list is EFI DVD/CDROM and it does not seem to fail that ie it hits option 1 and boots CDROM. \ [17:40] yes, you are booting in UEFI mode [17:40] the desktop build just completed has picked it up (but is oversized and needs investigation); not sure if server will be respun [17:41] cjwatson, ok I have DVD I can use to burn image on [17:41] cjwatson, so if I reseed now I should get the latest correct ? [17:42] yep [17:42] cjwatson, which build should I use ? daily-live/current ? or daily/current ? [17:42] the former [17:42] daily-live it is [17:43] cjwatson, will test that bad boy in couple of mts [17:50] pitti: howdy, I submitted another optimization to the WI tracker today as a merge proposal. Should speed it up a lot actually. [17:50] SpamapS: I saw, thanks! [17:52] pitti: I'm trying to add some useful little panels to the HTML report, like a list of assigned bug tasks in ubuntu.. but I don't want to add this to collect. I'm wondering, do you know if there is a launchpad/ajax proxy available on people.canonical.com? [17:52] SpamapS: I'm afraid I don't even know what an ajax proxy is :/ [17:52] pitti: I'm thinking of opening up an RT ticket to allow for one. That would let us put in some on demand stuff and not have to collect it all. [17:53] pitti: its just a program that would be running on there to get around javascript's "same-origin" restriction. [17:53] pitti: basically I can't ask launchpad.net for JSON from a script that originated on people.canonical.com === beuno-lunch is now known as beuno [17:54] pitti: but if we could have a script on people.canonical.com that proxied directly to api.launchpad.net, there's no problem. :-P [17:54] actually I wonder if launchpad supports JSONP .. [18:03] cjwatson, with that respun oversized disk, on an e6410 it looks like there is a grub menu, but selecting the first option just yields a black screen [18:04] superm1, I did not want to hear that ! vanhoof ^^ [18:05] superm1, on intel efi test bed.. its booting and installing as of now [18:06] vanhoof, I should try this iso on 4310 I have an make sure we see an install menu etc on maverick [18:06] superm1: seems that there are different results on different machines. I get a blank screen too [18:06] superm1: the next thing I'm going to try is the grub newreloc branch, since I'm becoming convinced that the initramfs isn't being loaded properly [18:06] but this is why I wanted somebody to try with a serial console [18:06] cjwatson, i can likely get a port replicator that has a serial port if it would be useful [18:07] it's amazingly hard to debug this when the amount of information you get is a blank screen [18:07] cjwatson, the new iso fails grub install [18:08] executing grub-install on /dev/sda failed ... [18:08] I will put up the logs in a minute [18:10] manjo: perhaps he doesnt have the fix that was just released? also there is 554569 which has helped a few people w/ 6410's, but its not been released yet [18:10] that might be a grub-installer bug; it probably shouldn't be offering device selection on EFI, and should be calling grub-install without a device argument [18:10] vanhoof: which fix? [18:13] cjwatson: 561802 [18:13] which was released today in .42, but is only resolving a bug for UMA based 6410's [18:13]