[00:05] SpamapS: thank psurbhi for that [01:03] cjwatson, say umm... is it known that the amd64 builds of grub-emu are broken? I get "invalid arch independent ELF magic" trying to load modules, but not on an i386 system === sanchaz is now known as sanchaz-away === jelmer is now known as Guest8056 === jjohansen1 is now known as jj-afk === bjf is now known as bjf[afk] === amitk-afk is now known as amitk === amitk is now known as amit-afk === amit-afk is now known as amitk === smb` is now known as smb [07:51] good morning! [07:54] good morning Mr Holbach :) [07:57] salut monsieur didrocks [07:57] comment ça va? [07:57] dholbach: très bien, et toi ? :) [07:58] très bien aussi - merci [08:01] * dholbach va chercher du café [08:06] dholbach: french speaking day for you? :) [08:06] didrocks, just a little bit :) === artnay_ is now known as artnay [08:55] anyone know if there was a build farm problem last night, i have an i386 and a powerpc build failure without logs [08:55] apw: Yeah, there were some issues. [08:56] apw: Not entirely resolved, but it should be mostly better now. Please retry. [08:56] We may do a mass-giveback later. [08:56] Once we have everything fixed. [08:56] wgrant, that sounds bad [08:56] But no guarantees. [08:56] not pkgmangler ? [08:57] No, internal Launchpad issues. [08:57] pkgbinarymangler is easily fixable. [09:01] wgrant, yay another successful launchpad release ? [09:04] apw: No, that's not for a couple of hours :) [09:05] Although this was an update to see if the release was safe... === hunger_ is now known as hunger === mthaddon changed the topic of #ubuntu-devel to: Launchpad down/read-only from 10:00-12:00 UTC for DB update | Archive: Open | maverick-proposed is now unfrozen | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/Help === Guest8056 is now known as jelmer [09:46] How long does it take to get approval of a sent message to the list? [09:56] rsajdok: between when I answered you last night and about now, I've been (a) having family time and then (b) in bed. patience! [09:57] you really need to cut donw on that bed stuff :P [09:57] there were a whole 7 messages in the queue when I last looked - not a huge backlog or anything [09:57] did you notice that antimony seems to have run out of space ? [09:57] so what else is new :P [09:57] * ogra wonders whom to ping [09:58] I'll look in a bit [09:58] heh [10:15] rsajdok: uh, this mail isn't really appropriate for ubuntu-devel - the package is clearly buildable by Ubuntu so it's basically a support request, and there isn't enough information in your pastebin entry to fix your problem even if it were appropriate [10:15] rsajdok: which bzr branch did you check out before running bzr-buildpackage? [10:19] rsajdok: I'd be happy to help you figure out your problem, just not on the ubuntu-devel mailing list === nijaba is now known as nijaba_afk [10:25] good morning [10:25] how do we report bugs for partner packages ? [10:26] they should have source package entries in Ubuntu in Launchpad [10:26] gstreamer0.10-fluendo-plugins-mp3-partner presents an acceptance dialog, but I am not alllowed to cancel the install [10:26] ubuntu-bug tells me it's not a genuine package [10:27] https://launchpad.net/ubuntu/+source/gstreamer0.10-fluendo-plugins-partner/+filebug (when LP comes back out of read-only mode) [10:28] ok, will do, thanks [10:35] cjwatson: yes, I did check out bzr branch, like description: http://unity.ubuntu.com/getinvolved/#coding [10:35] cjwatson: so, where is better place for this question? [10:36] rsajdok: I see your confusion. lp:unity is the upstream branch - it doesn't have packaging metadata, so you can't build it with bzr-buildpackage [10:39] rsajdok: looking at the source, I guess you need to use cmake to build it (not a build system I know very well). #ayatana can probably help if you have detailed questions on that [10:39] the packaging branch is at lp:~unity-team/unity/packaging. [10:39] rsajdok: you have build instructions at https://wiki.ubuntu.com/Unity/InstallationGuide [10:40] cjwatson: Where is better place to ask questions of involved unity? [10:44] rsajdok: I already suggested #ayatana, which I think is right - didrocks? [10:44] yep, this is the good place to be :) [10:47] cjwatson: thanks for wiki. This is it. [10:48] didrocks: thanks also! === nijaba_afk is now known as nijaba === mthaddon changed the topic of #ubuntu-devel to: Archive: Open | maverick-proposed is now unfrozen | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs [11:26] ev: thanks for the usb-creator upload [11:26] sure thing. Sorry I didn't get to it sooner [11:39] grr, one of these days I will do a man-db release and not screw something up [11:43] ogra: cleared up 27GB or so, hopefully that will keep us going for a bit [11:43] (well, rm -rf still running) [11:43] great [11:43] cant we have some additional disks ? [11:43] so we dont always hit the limit [11:45] feel free to file an RT, I gathered there were some physical limits [11:45] plus there are problems on the internal cdimage mirrors if the size goes up very much, so it's not just that one machine [11:45] hmm, k [11:46] the local archive mirror does tend to grow though [11:46] I wonder if I should just drop the separate universe mirror [11:46] long term it might be good though, if we one day start building more armel flavours the space might get eaten up faster [11:46] but that makes it easy to have accidents [11:46] if you do you're going to have to figure out hosting [11:46] it's a problem [11:47] well, we only need the temporary space during builds [11:47] but if you build in parallel that might be a lot [11:48] hosting => cdimage.ubuntu.com [11:48] not talking about antimony ... [11:48] right, hosting should be okayish, the resultimg images are rather small [11:49] *resulting [11:49] and currently we dont build many more flavours [11:49] (natty that is) === doko__ is now known as doko [11:51] cjwatson, oh, btw, feel free to ignore the armel build failure of d-i for now, i'm still waiting for a statement from the kernel team about the possibility of using linaro kernels for omap3, until then its fine to let it fail [11:52] ah, here, I can do some backup clearance [11:52] ogra_ac: ignoring :-) [11:56] ogra_ac: 93GB free now, should last for a while [11:56] yeah, sounds good === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann [12:44] mvo: Hi, do you have a minute to look at this libapt-pkg check from postgresql-debversion? http://paste.ubuntu.com/533447/ Do you have idea what's causing this? [12:45] pitti, is the natty.cfg under platform under revision control at all ? [12:46] apw: no, not any more; other projects use the wi tracker as well now, and I don't think it's appropriate to keep them all in trunk [12:46] pitti, yep understand why our configs wouldn't be in there, wondered if there was a branch for it, ie a place with just our configs into which we regularly merge trunk or ... its not in VCS [12:47] it's not a VCS right now [12:47] if its not thats fine, just don't want to do the wrong thing... thanks :) [12:47] if somebody wants to create one, I don't mind at all [13:02] * ogra_ac lols about none-kernel-n-misc ... apw now thats a funny spec [13:02] heh why funny ? [13:03] our left over crap spec [13:03] apw, you are aware that this addes another 5-10 items for canonical-arm to even produce such an image ? [13:04] unless the kernel team planned to build it [13:04] ogra_ac, why so? i swap in kernels into an existing image all the time [13:04] the item was to cover the fact that you need to know whether a linaro kernel is any good for making CDs or not? [13:04] ah, thats something the workitem should say ;) [13:04] i cant really say if the built initrd will be good, if jasper will work etc [13:05] [canonical-arm] to swap in a Linaro kernel into an existing CD image confirm feature set:TODO [13:05] is that better ? [13:05] unless i actually build it the way we build all our images, the preinstalled images we ship are more like live images [13:05] ogra_ac, yeah i have been droppiing replacement kernels into live CDs, its not 'easy' but its doable [13:05] yes, we cant say if it will work for preinstalled that way, but can at least roughly judge if the HW works [13:05] as long as you then put them on a USB stick anyhow [13:06] right [13:06] preinstalled images make that a lot easier than live ones, but its a bit more work than just replacing vmlinuz [13:06] yep you have to unwrap the initrd and replace the modules and roll it back up [13:07] nah [13:07] in preinstalled you just chroot into the rootfs and run update-initramfs ;) [13:07] ahh [13:07] the tricky part is that you need to do the bootloader bits by hand [13:07] i.e. run mkimage to create uImage and uInitrd for uboot [13:08] anyhow i've used the reworded item so you don't explode :) [13:08] and put them in the right places [13:08] i dont explode ;) [13:08] originally it just sounded like we should build an image [13:08] (through overwork) [13:08] which needs MIR etc [13:09] heh no, this is a pre-cursor activity, though if they arn't supporting them then its likely they fail before then [13:09] well, the kernel and security teams from ubuntu would have to support them [13:09] they would just offer the base tree but aligned with our master [13:10] and i suspect that the work is minor for security but i don't see where we will have resource to do that for sometime yet [13:10] so the only issue left to use them are config alignments and security updates [13:10] apw, well, dont you have two new arm positions ? [13:10] once these are filled one of them could work on that [13:11] so if it takes 2 months to fill them, and 2 months to train them, we'll have resource available after feature freeze [13:11] i assume one fulltime person is enough and it would load off most of the arm work to linaro [13:11] kernel freeze even [13:11] yeah, thats a bit late [13:11] though its likely that the only kernel for now will be omap3 [13:11] omap4 is handled differently anyway [13:11] and what is the use case for omap3 ? [13:12] it has teh biggest community in arm land [13:12] omap4> indeed [13:12] we dont want to lose them [13:12] oh, omap4 [13:12] contracts ;) [13:12] yeah happy we have the incentive and resource for omap4 [13:12] bryan will work full time on omap4 with TI as last release [13:12] yep [13:13] there wont be many changes apart from timing at TI side [13:13] apw: There are other teams making plans based on the understanding there will be an omap3 kernel. [13:13] so the only intresting part is omap3 [13:13] since we want to keep it for the community [13:13] ogra_ac, you wanted omap3 pulled out of master, why was that [13:13] given noone is sending anything to add to any hyperthetical omap3 branch [13:14] apw, because it got in your way wrt build time and it got into our way wrt flexibility for adding patches late in the cycle [13:14] though now you have nothing instead [13:14] having it in mainline vs a topic branch was always getting in our way [13:14] now i have a vibrant discussion with linaro [13:15] and hopefully wiht the kernel and security teams [13:15] heh well there is that [13:15] with the target to load all core maintenance work off to linaro [13:15] and only have the long trem tasks in karnel/security [13:15] *term [13:15] but if they provide no support for their kernels how do they end up doing anything maintenance wise [13:16] the omap3 kernel is pulled directly from our mainline [13:16] including the ubuntu sauce [13:16] and the existing config [13:16] so all i need is security commitment for post release [13:16] but we already had exactly that in our kernel before we ripped it out, if that is where it is coming from [13:17] so i am doing the work anyhow before release, and after we'd have to do it? [13:17] so thats lose lose lose for me ? [13:17] right, but you wont have to handle e.g. my $new_omap3_board misses patch XY [13:17] yeah we do, as they don't do any support after release [13:17] all the patchwork goes to linaro [13:18] they don't maintain any released versions, they move on to new ones and do not look back [13:18] so we could define that no SRUs happen for that kernel ;) [13:18] only security maintenance [13:18] then we still gained exactly nothing for adding linaro into the loop [13:18] which should be trivial given they are both the same tree [13:19] sure you do [13:19] * apw waits to be enlightened [13:19] you dont have to care for it at all during development [13:19] since linaro does that [13:19] except their tree comes from whats in our master branch [13:19] plus their patches [13:19] and i am providing the sauce and ocnfigs [13:19] how are they helping me at all [13:20] they maintain the arch specific config [13:20] not your job [13:20] they maintin everything thats arch specifc [13:20] you dont have to touch it [13:20] are they commited to an ubuntu config there? i heard they were going minimal on all their configs [13:20] well, thats discussable i think [13:21] how i see it is that during developemtn you shouldnt have to touch it at all [13:21] see now we have to have a discussion ... i am not convinced there is any time saving in here [13:21] if we'd just left it in master you'd have 2.6.37-rc2 ker [13:21] and post release you would take over security maintenance [13:21] kernels by now, instread of none [13:21] hmm [13:21] but you have the maintenance work, have to review patches etc [13:22] OMAP3 is mostly upstream though isn't it [13:22] i'm fine not having omap3 before alpha2 if that turns into less duplication [13:22] as its nearly so old as to being dead [13:22] its mostly upstream plus linux-omap [13:22] the work intensive part is the -omap tree merges [13:23] which adds i.e. support for extra boards etc [13:23] you didn't need any of that last cycle [13:23] look at all the IGEP2 bugs that are still open [13:23] with plenty of them being SRU [13:24] there is a *lot* omap3 HW out there my guess would be that we only support 20% yet [13:24] so there is more to come [13:24] ok so i'll assume that sometime someone will tell us where omap3 is coming from :) [13:24] and in the meantime i can definatly strip the omap3 configs from our tree [13:24] would you prefer to maintin it ? [13:24] geser: looking now [13:25] ogra_ac, no i just don't want any supprises [13:25] my whole idea was to putt workload off the kernel team [13:25] so i keep poking the anthill with my stick [13:25] and you dont sound like i did [13:25] yep, you have convinced me you are getting something different from linaro if you take their kernel so there is something in it for you [13:26] sounds like you think you don't need any help from kernel till release [13:26] i might [13:26] and you know when we might have resource to help if you do [13:26] geser: was this working before? [13:26] thats still open, and thats why i started the ML discussion [13:26] i'm a bit sad that nearly everyone chimed in on that apart from kernel and security teams [13:27] ogra_ac, to my mind your team is the only one which can determine whether that branch is acceptable [13:27] right, but also only for the boards we have [13:27] as for not responding, that is cause we didn't at the time at least have a clue if we had resource [13:27] we know now we do not until the heads are filled [13:27] the only real resource that can determine it is the community [13:27] /win 15 [13:27] geser: hm, that seems to be working for me (that snippet) [13:28] ogra_ac, your team doesn't have any omap3 to test with ? [13:28] right, *i* know that you dont have resources, the people discussing in the thread dont [13:28] we have beagleboards [13:28] apw and ogra_ac: I know there will be some community testing of omap3. [13:28] geser: with g++4.4, let me try 4.5 [13:28] ScottK, yeah, i would expect so [13:28] ogra_ac, yep someone needs to respond now the position has shaken out, i'll poke people [13:28] mvo: this was from a natty pbuilder [13:28] apw, thanks a lot :) [13:31] geser: ok, let me try that (for the record, g++-4.5 compiled it too) [13:32] mvo: I've tried now to build the package in my maverick pbuilder and it worked there, only natty fails [13:40] geser: I can reproduce it here now [13:42] Does the i386 build failure at https://launchpad.net/ubuntu/natty/+source/qemu-kvm/0.13.0+noroms-0ubuntu4 look to anyone like anything but a natty toolchain failure? === zyga is now known as zyga-food [13:48] hallyn: It's a gcc problem. You might try to grab the previous gcc-4.5 version and see if you can build it. The latest gcc-4.5 update is not regression free. [13:49] ScottK: ok, thanks. can i specify the version with build-depends, i suppose? [13:50] No. [13:50] drat [13:50] You'll need to grab the old one from LP and try it locally. [13:50] well, i know under maverick it compiled fine [13:50] i'm just wondering whether to ask kirkland to just re-try the official build, and hope that the dice get cast in my favor this round [13:51] geser: hm, I just checked the code and I can not spot the problem - doko, do you have a idea what changed in g++ in natty that makes http://paste.ubuntu.com/533447/plain/ fail? in mav with g++-4.5 that builds fine [13:52] mvo: no, does it work with gcc-snapshot? [13:54] doko: Does gcc-snapshot use linaro or fsf upstream? [13:54] ScottK: fsf [13:55] doko: Speaking of which, any thoughts on Bug #675347? [13:55] Launchpad bug 675347 in gcc-4.5 (Ubuntu Natty) "volatile int causes inline assembly build failure" [High,Confirmed] https://launchpad.net/bugs/675347 [13:56] ScottK: as mentioned yesterday, please ask jbrown on #linaro [13:56] OK. [13:56] mvo, doko: adding --no-as-needed to the -Wl flags makes it link [13:56] we should just rewrite everything in shell [13:57] would fix all compiler issues [13:58] geser: which lib has the symbol? === zul is now known as ep === ep is now known as zul [14:01] doko: it should be in libapt-pkg, see http://paste.ubuntu.com/533466/ for the ldd of the linked binary and objdump -T for libapt-pkg.so [14:07] geser. mvo: maybe fix the conftest, so that the library is really linked? [14:08] doko: hm? is -lapt-pkg not enough to really link it? [14:08] doko: what you mean with really linked? the configure script used "x86_64-linux-gnu-g++ -o conftest -g -O2 -Wl,-Bsymbolic-functions -lapt-pkg conftest.cpp" [14:09] I used "g++ -o conftest -g -O2 -Wl,-Bsymbolic-functions,--no-as-needed -lapt-pkg conftest.cpp" to make it link [14:09] mvo: apparently the symbol you are checking for can be used without the lib [14:09] it's included from the a header [14:10] doko: its in the header as "extern" - is that not enough? [14:10] mvo: apparently not with --as-needed [14:11] doko: hmhm [14:13] mvo: hmm, the test works on i386 [14:14] I'm on amd64 if it matters [14:18] geser: can't reproduce it here :-/ [14:18] doko: on natty? I got it while test-building a package in my natty pbuilder [14:19] yes, natty [14:21] hmm, mvo perhaps you can help doko how to reproduce it as you managed to reproduce it too [14:24] when I copy the code from the paste and try "g++ -o conftest -g -O2 -Wl,-Bsymbolic-functions -lapt-pkg conftest.cpp" I get the linking error === yofel_ is now known as yofel [14:30] geser: my libapt-pkg-dev is 0.8.8ubuntu3 [14:30] the same [14:32] g++ is 4:4.5.1-1ubuntu3 and g++-4.5 is 4.5.1-10ubuntu1 [14:33] * geser is away for around 2h === zyga-food is now known as zyga [14:40] didrocks, did you open a bug about the gcc-4.5 issue breaking gnome-settings-daemon? [14:40] or just pinged doko? [14:40] I think other sources fail the same way [14:41] seb128: I just pinged doko and gave him some pastebin as examples [14:42] doko, did you have time to investigate the issue didrocks pinged you about? do you need a bug report? [14:50] james_w: what is the best way if I have packaging in a bzr-builder compatible branch (i.e. just the packging files like rules, watch, no debian/ dir) and want to build a source pkg from that. I basicly want to say "bzr-buildpackage -S" from such a branch (if possible :) [14:50] mvo, --merge [14:51] *cough* [14:52] thanks james_w [14:53] doko: hm, odd - on my normal natty system it works, in my pbuider it does not, let me try to figure out what is different === azul_ is now known as jodh === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [15:00] pitti, on the 'overall cycle' versions of the burn-down charts, what is _not_ included in the graph that is included in the tables below? I added up the tables and found I had 129 tasks, but when I put that as the burn down start I find the graph is somewhat short at about 118 entries .. and am wondering why [15:02] doko: aha! funny (or not). order matters: "g++ -o lala -lapt-pkg lala.cc" fails, but "g++ -o lala lala.cc -lapt-pkg" does no (<- geser) [15:03] mvo: ahh, so the fix should be easy [15:04] doko: well, its all genearted by configure.ac [15:04] doko, hey [15:04] doko, so I've sources failing with gcc-4.5, I think it's the same issue that didrocks pinged you about yesterday [15:04] doko, should I make those use an another gcc version for now? [15:06] seb128: didrocks wanted to file a bug report, I didn't see one yet ... [15:06] doko: you didn't answered me if you wanted it and asking for others questions… I was taking that as a "no" [15:07] hmm ... [15:07] hallyn: i was going to merge your last proposal and send that for a build [15:07] hallyn: cool? [15:08] didrocks, can you open a bug now? [15:08] now that it's a clear "yes", sure I can [15:08] geser: something like http://paste.ubuntu.com/533486/ should work [15:13] Who is able to approve blueprints for Natty? Is it anyone in Ubuntu Drivers? [15:15] doko: seb128: bug #676519 [15:15] Launchpad bug 676519 in gcc-4.5 (Ubuntu) "link failing despite the right linking arguments are presents on command line" [Undecided,New] https://launchpad.net/bugs/676519 [15:15] didrocks, thanks [15:15] didrocks: this smells like mvo's problem above. put the objects before the libs [15:16] doko: indeed, that worked [15:16] I guess a common way of doing it before was using LDFLAGS to smuggle in libs [15:16] where LIBS should be used [15:16] yeah ... [15:16] or LDLIBS, yes [15:16] especially on configure tests its a bit anoying, but *shrug* [15:17] (LDLIBS for make's implicit rules) [15:17] cjwatson: which is the more "correct" one? [15:17] cjwatson: aha, ok [15:18] kirkland: cool, thanks [15:18] kirkland: and if it fails to build, then just resend it. [15:18] cause the toolchain is eating us for breakfast [15:34] doko, bug #676519 [15:34] Launchpad bug 676519 in gnome-settings-daemon (Ubuntu) "link failing despite the right linking arguments are presents on command line" [Undecided,New] https://launchpad.net/bugs/676519 [15:34] doko, you don't consider that a regression from gcc? [15:35] we have several sources failing this way, that used to work, is there any reason gcc couldn't handle the other order? [15:35] seb128: yes, --as-needed. it's not a regression, it's exposing a sloppyness in the test case [15:36] it was working some days ago with --as-needed [15:36] no [15:36] the previous upload from those source in natty worked [15:36] --as-needed was introduced on Monday [15:36] and --as--needed was in place since it failed due to it [15:36] so --as-needed is different from the dso changes? [15:37] --no-add-needed is in place since the opening of natty, --as-needed since Monday [15:38] doko: mumble? [15:38] life/win 13 [15:39] bah! (sorry, I should really add gnome-do to my default session!) [15:39] pitti, Could you accept the kernels for maverick and lucid so they get build [15:41] doko, I don't get why the object have to be before? [15:41] the gcc man says [15:41] gcc [-c|-S|-E] [-std=standard] [15:41] ... [15:41] [-o outfile] [@file] infile... [15:41] that ought to work in this order no? === bjf[afk] is now known as bjf [15:42] no, the order of objects does matter, same for libs [15:43] yeah, this is traditional unix linker stuff [15:43] gcc's been a bit permissive in the past so people have got a bit sloppy [15:44] but the way you've generally had to do it is that objects that provide symbols used by other objects need to come later [15:44] so I guess in a Makefile.am the .la should come before the _LIBS in a _LDADD [15:45] NOTIFICATION_AREA_LDADD = \ [15:45] $(NOTIFICATION_AREA_LIBS) \ [15:45] libtray.la [15:45] is failing because the .la is after the _LIBS? [15:46] depends, does libtray.la use symbols from $(NOTIFICATION_AREA_LIBS)? [15:46] yes [15:47] then yes [15:48] hum ok, I'm not sure how to explain that to upstream in the bug report though [15:49] "breaks with ld --as-needed" should be enough? [15:49] we're not the only distribution trying this [15:49] well it seems fedora has dso linking on and it doesn't break for them [15:49] well point is that this order works on other distros [15:50] or at least on fedora and opensuse [15:50] so I'm not sure how the way we do it is different or pickier [15:50] * ScottK also doesn't recall this being disucssed in the planned toolchain changes. [15:57] seb128: no, fedora doesn't have it, but OpenSuse has [16:01] hum, got disconnected [16:01] doko, then I need to check with vuntz why he doesn't get the issue on opensuse with the same tarball === diwic is now known as diwic_afk === tkamppeter_ is now known as tkamppeter [16:55] kees: is it still fast ? :) [17:02] mvo: thanks, works without any further changes === jam1 is now known as jam [17:05] geser: cool === jdstrand is now known as jdstrand_ [17:09] I guess the fixes for the missing DSO linking done to some package (add the lib to LDFLAGS) won't work then anymore and the packages FTBFS again [17:27] cjwatson, erm, bug 673504 is not a duplicate ... (beagle XM isnt omap4 but omap3) [17:27] Launchpad bug 673504 in linux-ti-omap4 (Ubuntu) "Pandaboard chooses a new IP address on each boot" [High,Triaged] https://launchpad.net/bugs/673504 [17:28] err [17:28] Bug 673509 i mean [17:28] Launchpad bug 673509 in linux (Ubuntu) "Beagleboard-xm chooses a new IP address on each boot (dup-of: 673504)" [Undecided,Confirmed] https://launchpad.net/bugs/673509 [17:28] * ogra_ac looks what happened there [17:33] wow, this put-each-tty-in-a-cgroup patch works beautifully [17:34] * SpamapS is having a bout with his mad-scientist side that wants to spawn 10 ec2 c1.medium's to grep through the entire archive for bash tab completion scripts... [17:34] cjwatson: do you bother using the upstream (top level) 'ubiquity' project in LP [17:35] SpamapS: Elastic Map Reduce? [17:36] SpamapS: Although apt-file is probably faster :-P [17:37] ebroder: I actually need to look at the content of the scripts, so apt-file would just produce the list of stuff to map/reduce. ;) [17:59] lifeless: let me try again... [18:01] cjwatson: I'm slightly confused by your e-mail. Is the conclusion that you're going to turn Lua on for 1.99 and we can go forward with that? Or do you want me to look into doing the hwmatch stuff as a C module? [18:23] ajmitch: ping? I see you grabbed the php5 merge (https://merges.ubuntu.com/main.html) ... [18:25] SpamapS: that's probably an old comment, but I can do it if you'd like :) [18:25] ajmitch: no, I am working on it, so I'll clear that out. ;) [18:25] ok [18:28] SpamapS: it would have been a comment from a previous release, they should get cleared automatically now [18:28] ajmitch: hm.. maybe a bug or something [18:30] SpamapS: yeah, a bug that was fixed but the previous comments haven't been cleared out for packages that weren't showing [18:30] no big issue though [18:40] yes, cjwatson has fixed this bug, but if comment is old, it has to be updated. after update, comment won't be saved anymore === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann === zul_ is now known as zul [18:57] hrm, something broken in natty with the LDAP/SASL libs.. [18:57] configure: error: LDAP SASL check failed. Please check config.log for more information. [18:59] zul: ^^ thats from php5 [18:59] zul: current and merged versions [18:59] SpamapS: umm...interesting [19:00] zul: help me with sbuild/schroot .. if I wanted it to drop me to the bash command line instead of kicking me out of sbuild.. can I do that with sbuild or do I have to sort of emulate it through schroot'ing in and then making stuff happen? === deryck is now known as deryck[lunch] [19:01] SpamapS: schroot -c -u [19:02] zul: ok, but then I need to install the build-deps .. [19:02] zul: so -u root, then su to my non-root user after that? [19:03] SpamapS: Do you know about schroot -bc, -rc, and -ec? [19:03] you can [19:03] ebroder: the man page doesn't seem to mention a -b [19:03]