=== PaulW2U is now known as G4MBY === dendrobates is now known as dendro-afk === doko_ is now known as doko === bladernr_ is now known as bladernr_afk [05:03] Good morning [07:04] apachelogger_: hey Harald, how are you? do you know if anyone from the Kubuntu team is interested in testing the alternate candidates? If not, we can just skip them for A1 and just release desktop/DVD [07:05] apachelogger_: also, is there anything new in Kubuntu A1 which should be mentioned in teh announcement? === tkamppeter_ is now known as tkamppeter === ubott2 is now known as ubottu === smb` is now known as smb [08:58] cjwatson, jamespage: http://people.canonical.com/~pitti/tmp/main-promotions.svg is a graph which represents the source/binary -> main section of http://people.canonical.com/~ubuntu-archive/component-mismatches.txt [08:58] cjwatson, jamespage: do you have any suggestions how to improve it? [08:59] note that I already tried to convince dot to make the layout a little more quadratic, but it insists putting all the root nodes into one straight line [09:00] * pitti ♥ graphs [09:00] doko: ^ you are looking on c-m a lot, too, any suggestions? [09:02] (fixed title) [09:04] I'll add a legend [09:40] pitti: that is really useful; what are black arrows? [09:40] jamespage: ah, I'll add that to the legend; these are normal Depends: [09:41] jamespage: http://people.canonical.com/~pitti/tmp/main-promotions.svg updated [09:41] pitti: I think I should re-introduce a dependency on maven-debian-helper to see how it copes :-) [09:42] thats what normally causes the java explosion! [09:42] yeah, you should see a huge graph hanging off just one package [09:42] back then it was totally unreadable indeed, and I really wished for a graph like this [09:42] pitti: Is component-mismatches misbehaving on armhf? libc6-*-armel is a build-dep of gcc-4.6 and eglibc, demoting it seems suboptimal. :P [09:42] now it's usable, but the graph is still better to visualize [09:42] pitti: agreed [09:42] one is bound to pop up sooner or later [09:43] pitti: (And I just demoted nscd, not sure how that ended up mismatched) [09:44] infinity: hm, apparently so; it doesn't have armhf in the germinate part, but it does for read_current_binaries [09:44] infinity: will investigate [09:44] cjwatson, jamespage: I also want to improve c-m to point to MIR bugs [10:21] pitti: i've started adding, http://people.ubuntu.com/~davewalker/component-mismatches-mir-track.html to the current output. It would mean changing the output to html, rather than text.. is this ok? [10:21] Daviey: oh, you already did that? [10:22] I was just working on integrating this into the reports [10:22] Daviey: for the .txt I'd just add somethign like [10:22] MIR: https://launchpad.net/bugs/12345, Incomplete [10:22] Launchpad bug 12345 in isdnutils (Ubuntu) "isdn does not work, fritz avm (pnp?)" [Medium,Fix released] [10:22] yeah, shut up ubottu [10:22] Daviey: but for the graph we can make the MIRs clickable [10:23] Daviey: we post-process the .txt output in at least one place, but we should get rid of that [10:23] pitti: i suppose i am lazy, but it provides a pre-canned url to raise one.. overkill? [10:23] Daviey: we can't pre-can them so that ubuntu-mir gets automatically subscribed, but we can certainly do a +filebug link [10:24] not clickable in .txt, but at least c&p [10:24] Daviey: but this is just the first step [10:24] Daviey: once I moved the "diff" processing to something saner, we can just turn it to html [10:27] cjwatson: Would you consider changing /etc/default/grub : GRUB_DEFAULT=0 -> GRUB_DEFAULT=saved ? [10:29] Unless i am mistaken, it doesn't cause any change in behaviour, unless people choose to use the saved_entry? [10:35] hah! autogenerated: http://people.canonical.com/~ubuntu-archive/component-mismatches.svg [10:37] nice [10:43] pitti: it is much easier to read. [10:43] I'll integrate MIR bugs there, too === yofel_ is now known as yofel [10:48] too bad that we don't have an approved MIR; I guess I'll temporarily flip one to fix committed for testing proper colors in teh svg [10:50] pitti, what are you generating the svgs from [10:50] (what format) [10:50] apw: component-mismatches generates a dot file [10:50] http://people.canonical.com/~ubuntu-archive/component-mismatches.dot [10:51] then I run that through dot [10:51] apw: i. e. graphviz [10:51] yep, met that one :) [10:52] it's how I drew https://wiki.ubuntu.com/Hotkeys/Architecture or http://people.canonical.com/~pitti/talks/efficient-bug-handling/bug-lifecycle.pdf, it's pretty nice [10:52] although it's a bit like LaTeX: while its default behaviour is reasonable, tweaking the output layout is really hard :/ [10:59] pitti: nice, now could you add a bug number to the package if you find one for the package? open report, with ubuntu-mir as subscriber> [10:59] ? [10:59] doko: already done for text, doing for SVG [10:59] next report will have it [11:00] pitti: Should i land my stuff, or have you reproduced it? [11:00] Daviey: I already had it implemented when you pinged; it's not a separate report (and I don't think we need one) [11:00] let's just HTMLify the main one [11:01] pitti: no, that was a first draft done when we discussed it ~2 months ago. The latest stuff i did was against the now open sourced main report generator. [11:02] ho hum, nevermind :) [11:02] Daviey: ah, sorry, wasn't aware of that one [11:05] pitti, where are we with this installer issue ... i am completly unable to reporoduce it as of yesterday afternoon, and cannot fathom what has changed [11:05] apw: ah, jibel set up a jenkins job for it and has found out how to reproduce it there in 22/33 cases [11:05] with a non-interactive test case [11:06] apw: he wondered how to annotate the VM to pull out some information; ISTR that you had annotations, but you can't reproduce the bug [11:06] sounds perfect to put these two together :) [11:07] pitti, have we made any decision about what to do about it for A1, i assume as its not very reproducible outside of jibels case we won't be holding for it ? [11:07] apw: no, we won't hold it for that; we documented it [11:07] workaround: just install again [11:07] yeah, fair enough [11:08] jibel, in your test rig, are you able to sub in an updated kernel easily ? [11:08] seems the first logical step there is to see if it really is write which is returning EINVAL [11:10] apw, I think so, I'm pxe booting the VM, so could pull an updated kernel. I don't know if there's a kernel version check that would block the install afterwards. [11:13] pitti, TheMuso: libatk-wrapper-java-jni needs then needs some symlinks to install into the bootclasspath. is this tested/done? [11:14] Daviey, doko: http://people.canonical.com/~pitti/tmp/main-promotions.svg [11:14] doko: deferring to TheMuso [11:15] Daviey: ah, will add clickable links for +filebug [11:16] pitti: instead of approved/unapproved MIR, maybe differentiate between (new/incomplete) and and anything else? [11:16] doko: what's the difference? [11:16] jibel, i'd be supprised if there was a version check, in the install image it may put the wrong kernel on, but its the boot kernel that matters [11:16] jibel, for the problem in hand i think [11:16] pitti: nice... new/incomplete does make sense [11:16] doko: you want to differentiate between unassigned and assigned unapproved, too? [11:16] nah [11:16] doko: I think the difference between "confirmed" and "fixcommitted" is quite important here [11:17] approved == ['In Progress', 'Fix Committed', 'Fix Released'] [11:17] I'm happy to handle "wontfix" separately [11:17] pitti, well, that's a distinction for one of the shortest periods [11:17] yes, but I'd like to see which ones can be actioned immediately [11:18] pitti: but I'd like to see like Daviey's placeholder for suds [11:18] doko: ah, so "incomplete" separately make sense indeed [11:19] but "new" is also for submitted MIRs which are not assigned yet, so I don't think that's very special [11:20] well, both new and incomplete show that some action is needed [11:23] jibel, ok i will get you a new kernel with EINTR from write annotated, we should see it in dmesg then if its comming form there; and we can use it to test if you can sub kernels easily [11:26] Daviey, doko: done: http://people.canonical.com/~pitti/tmp/main-promotions.svg === _salem is now known as salem_ [11:26] clickable links for filing a bug, and handling "incomplet" [11:26] apw, we start getting a fair amount of duplicates, but for A1 the workaround is fine. [11:31] Daviey, doko: http://people.canonical.com/~pitti/tmp/main-promotions.svg fixed harder now, and split legend [11:31] pitti: that rocks [11:31] I temporarily set the subunit MIR to "Fix committed" for testing [11:32] pitti: looks great!! [11:33] pitti: Now you just need to get the colours approved for brand guidelines. :) [11:33] psychologically they are probably all wrong and unharmonic anyway [11:33] I'm not good at that [11:33] http://people.canonical.com/~ubuntu-archive/component-mismatches.txt [11:33] there, MIR status, too [11:33] doko: ^ FYI [11:34] I'll mop this up and announce it properly to ubuntu-archive@ [11:34] \o/ [11:36] pitti, heh, then add the component in the text was well (to easier find the top-level dependencies), or move them to a separate section [11:36] would be nice if everything can live in ~ubuntu-archive [11:37] doko: marking top-level components> yes, can do [11:37] doko: I just committed it to ubuntu-archive-tools [11:37] doko: ~pitti/tmp was just testing before I committed [11:38] http://people.canonical.com/~ubuntu-archive/component-mismatches.svg [11:58] barry: it's nearly 2012 and I'm writing new code in Python 2.6. :P [12:12] doko: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt has (MAIN) tags now, ok? [12:13] and http://people.canonical.com/~ubuntu-archive/component-mismatches.svg is fixed to have URLs for every node [12:14] Daviey: ^ so that points out rather nicely that it would make sense to drop the python-coverage b-dep from keystone [12:15] hm, it doesn't link to the keystone MIR, debugging/fixing [12:16] ah, just forgot to run dot, working now [12:16] pitti, looks fine [12:17] doko: really gets high time to HTMLify this to get some color and links :) [12:17] but for now, back to alpha-1 stuff [12:18] pitti: yeah, I was hoping somebody would do that once it was in lp:ubuntu-archive-tools :) [12:19] it greatly helps indeed [12:19] cjwatson: still need to test-run it on lillypilly because it needs the germinate/ubuntu mirrors, but it's still easy [12:19] * pitti sends announcement [12:19] pitti: you can rsync those locally if necessary [12:19] right, but they are quite huge [12:20] true [12:20] cp component-mismatches cmnew; vi cmnew; ./cmnew ... [12:20] and when done, scp cmnew to my local workstation, bzr commit, and pull on lillypilly [12:20] Daviey: I have a vague memory in the back of my mind somewhere that I'd looked at GRUB_DEFAULT=saved as a default and decided that it was troublesome for some reason, although I'm afraid I don't seem to have written down why and can't remember it right now. Sorry, I know that's not the best answer [12:20] admittedly not quite the most elegant way, but avoids downloading all this :) [12:21] Daviey: it's possible I was concerned about it not working in some common environments yet [12:22] (btrfs, lvm, raid) [12:27] Daviey: nagios-plugins is the only remaining package which still needs libmysqlclient16-dev, plus two handful of libmysqlclient16 rdepends; is that still on the server team's radar? [12:28] Daviey: I can demote -5.1 for now (main is fixed), but I suppose we want it removed from the archive entirely at some point? [12:29] ok, no kubuntu alternate tester, so we won't respin that and won't release with it unless someone wants to test them quickly [12:29] which means.. [12:30] Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [12:30] ... lifting freeze, happy uploading! === infinity changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [12:31] pitti: Changing topics works better when you actually do. ;) [12:32] infinity: argh, I forgot /topic, didn't I [12:32] thanks [12:34] doko: Do you have a bash FTBFS fix in the pipeline? [12:36] infinity, yes [12:36] doko: \o/ [12:37] lool: Which packages do you have queued up for -lm fixes? May as well upload 'em all now. [12:37] * infinity finds it somewhat handy that we have a new port to expose all the -lm breakage. It's like a free rebuild test. :P [12:38] * infinity blinks at the mozjs failure. [12:41] * ogra_ wionders why ruby hangs during build [12:42] ogra_: My bet's the same kernel bug that causes python and perl testsuites to (sometimes) hang. It's on the list of things to poke at. [12:42] k [12:42] ogra_: There's a claim that more recent kernels fix it, if you're in a local-experimentation-and-bisecting mood. [12:42] not really :P [12:43] So, that's a yes? [12:43] what kernel on what board ? [12:44] linaro kernels on pandas supposedly work. Ours seem not to. [12:44] But this is all second-hand. [12:45] And it's transient too. [12:45] Given that perl has similar issues, and the last perl build was on a panda and worked fine. [12:45] So, I dunno. [12:45] But I don't like the idea of DoSing our buildds with testsuites either. :P [13:05] hi [13:05] we have 'ubuntu-desktop' metapackage to install whole ubuntu desktop but do we have something similar to install all *-dev packages and tools to develop for ubuntu-desktop? [13:06] jincreator, ok here are kernels with EINVAL reporting for write added, can you see if you can reproduce with those and if so get me a dmesg from the machine: http://people.canonical.com/~apw/lp894768-precise/ [13:06] jincreator, sorry not for you ... [13:06] apw: I know. That's OK. :) [13:07] hrw, are you volunteering ? [13:07] :) [13:07] infinity, I uploaded ossp-uuid and bluez to build without php and gstreamer, will need to revert these changes later [13:08] ogra_: I am making something like this for linaro images - but only add -dev packages (as we want sysroots rather then development images) [13:08] ogra_: https://code.launchpad.net/~hrw/linaro-seeds/multistrap-configs-for-sysroots [13:08] doko: I noticed. I could have just built them in the stage-2 archive. [13:09] doko: But your way works too. :P [13:09] hrw: All the -dev packages that match ubuntu-desktop would be (A) huge, and (B) probably impossible (there will be conflicts) [13:10] hrw, did you think about using grep-dctrl ? [13:10] In fact, I know there are conflicts. [13:11] ogra_: instead of grep|cut? [13:11] yeah [13:11] ogra_: not yet, but may take a look === MacSlow is now known as MacSlow|lunch [13:12] doko: So, that mozjs failure puzles me. The config test is bombing on a failure to find a header that's definitely there. And it works on amd64. [13:13] Riddell: can the Kubuntu team deal with bug 894805? It's more of a KDE thing than Foundations really; while I'm sure I could remove the requirement for 'Qt' to exist in /usr/lib/qt4/imports/, I don't know the system well enough to know whether that's the right thing to do [13:13] Launchpad bug 894805 in cmake (Ubuntu Oneiric) "QT_IMPORTS_DIR is not defined when no QML plugins are installed" [Undecided,New] https://launchpad.net/bugs/894805 [13:14] infinity, do you have the test program? [13:14] ogra_: grep is faster then grep-available [13:14] pitti: this is very nice: http://people.canonical.com/~ubuntu-archive/component-mismatches.svg [13:15] doko: I have the config.log. Not sure if it left the test around. [13:15] ogra_: 0.006s contra 0.189s [13:16] grep is probably faster in raw terms; grep-dctrl is normally a lot more convenient though [13:16] infinity: ubuntu-desktop has two libjpeg libraries: 62 and 8 - I just install libjpeg-dev to solve that [13:16] doko: Oh, duh, the test code is in the log. ;) [13:16] doko: http://paste.ubuntu.com/755981/ [13:17] cjwatson: for shell script which has to go though 400-4000 calls of command I prefer faster solution then nicer one [13:17] infinity, try to uninstall the multilib libc6-dev? [13:18] doko: It's not installed. [13:18] hrw: if that's true then you should probably be refactoring to not require forking 400-4000 subprocesses in the first place. [13:20] hrw: e.g. use grep-dctrl with a constructed regex to match all the package names at once, and run sed in bulk over all of those [13:20] doko: I mean, I'd have just assumed it needs a -I/usr/include/ or something, but then it works on amd64, so... Confused. [13:20] hrw: complaining about the speed of grep-dctrl when that script is so inefficient in its own right is kind of missing the point. :-) [13:20] infinity, works here [13:21] doko: Where "here" is..? [13:21] cjwatson: you are right [13:22] doko: Wait. I just noticed that it's got a -mfloat-abi=softfp in the command line there. Nevermind. Off to dig. [13:23] doko: (Yay for being blind) [13:24] AC_MSG_CHECKING(for ARM NEON support in compiler) [13:24] _SAVE_CFLAGS="$CFLAGS" [13:24] if test "$GNU_CC"; then [13:24] # gcc needs -mfpu=neon to recognize NEON instructions [13:24] CFLAGS="$CFLAGS -mfpu=neon -mfloat-abi=softfp" [13:24] fi [13:24] AC_TRY_COMPILE([], [13:24] [asm("vadd.i8 d0, d0, d0");], [13:24] result="yes", result="no") [13:24] AC_MSG_RESULT("$result") [13:24] if test "$result" = "yes"; then [13:24] AC_DEFINE(HAVE_ARM_NEON) [13:24] HAVE_ARM_NEON=1 [13:24] fi [13:25] CFLAGS="$_SAVE_CFLAGS" [13:25] AC_SUBST(HAVE_ARM_NEON) [13:25] infinity, broken upstream test [13:25] doko: Quite. [13:25] and even for armel [13:25] I wish upstreams would stop trying to second-guess my compiler. :/ [13:25] we don't want to default to neon yet [13:26] No, we really don't. [13:44] jibel, ok here are kernels with EINVAL reporting for write added, can you see if you can reproduce with those and if so get me a dmesg from the machine: http://people.canonical.com/~apw/lp894768-precise/ [13:44] jibel, yay right person this time [13:49] apw, thanks. I'll first try in a VM with ubiquity's code fragment triggering the error and if I can't reproduce in isolation, I'll install an iso with this custom kernel. I'll let you know how it goes. [13:49] jibel, thanks sounds excellent [13:50] apw: iw/crda ping [13:50] apw: arm kernel ping [13:51] doko, iw/crda> is that the component missmatch between the new crda and iw ? [13:51] doko, arm kernel> i've blanked this one, remind me [13:51] hardfloat ? [13:51] ogra_, ? [13:52] do we have armhf in all kernel packages yet ? [13:52] as a target arch [13:52] ogra_, as far as i know everything is there, but i have nothing to test it on [13:52] ogra_, if there are problems with whats in precise tip i am unaware of them [13:52] apw, yes, the mismatch [13:53] doko, ok i think i forgot to poke tim and have made a note to do so [13:53] apw, the kernel issue is bug 861296 [13:53] Launchpad bug 861296 in linux (Ubuntu) "mmap fails to allocate 2030Mb heap on ARM" [High,Confirmed] https://launchpad.net/bugs/861296 [13:53] ah [13:53] apw: either make it a suggest, or promote [13:53] * ogra_ shuts up stopping to get people on the wrong track [13:54] doko, iw/crda> will pass that along [13:54] apw: I believe the build dies in kernel-wedge. There's a build running on the buildds right now to confirm that. [13:54] infinity, ok, as soon as you have a build log poke me so i can look [13:56] doko, arm> is that hurting the precise builds, or is it just armhf [13:56] just ... tsk [13:56] :) [13:56] s/just// [13:56] apw, we have some larger java packages which fail to build because of this [13:57] doko, ok, seems ppisati is off the air, will poke as soon as i get a chance [13:57] and the kernels used are running lucid and oneiric, and precise [13:57] iirc he is moving houses today [13:57] doko, its the buildd kernel which is the issue here right? so if we provided builds for those we would unstick you yes? [13:57] regardless of sru cycle time [13:58] doko: ppisati was on it, AFAIK, and had GrueMaster and lamont test some kernels. [13:58] infinity, yeah looks like the testing was good across the board if the bug is right [13:58] infinity, yes, the kernels were tested [13:58] apw: Then upload away? ;) [13:58] apw: We can convince lamont to install from -proposed. [13:59] infinity, that assumes I know where the patches you tested are [13:59] apw: Oh. Yeah. Then perhaps we wait for ppisati. :P [13:59] with ppisati unexpectedly offline (2 days early) i may not have them [13:59] i know he was ripped from the new early by his provider so he may not have been prepared yet [14:00] apw: I don't think it's blocking us so urgently that we can't wait for Monday. [14:00] (We may have another kernel bug that's actually more urgent, but it needs tracking and proving that it's actually a kernel bug before I file anything...) [14:00] infinity, ok will see what i can find and make it pp's first job [14:00] infinity, ok, and let me know about the kernel-wedge thing === MacSlow|lunch is now known as MacSlow [14:09] argh, someone binNEWed python-gi to universe, rendering half of the desktop uninstallable; /me fixes [14:11] I fixed that a few minutes ago [14:11] I'm fairly careful with new-binary-debian-universe nowadays; I tend to replace 'accept' with 'info' and look through for things in main first [14:11] thanks === Laney is now known as Guest60660 === bladernr_afk is now known as bladernr_ [14:27] pitti, awesome component-mismatches svg :) [14:27] mterry: :) [14:27] pitti, you should join #ubuntu+1-maint [14:27] That's where the cool kids hang out [14:27] lol [14:27] heh [14:27] then complain that we have a separate desktop channel [14:28] (argh another channel) [14:28] but then they do sub channel for stuff like maintaining the current distro ;-) [14:28] I desperately try to keep them < 10 so that I can switch to all of them with a key combo [14:28] and don't have to read too much [14:28] pitti: wow. I have 80-ish. I recently cut down from 150... [14:28] is that so high traffic that it needs to be out of devel? [14:29] seb128, last month we were using it for simple messages like "I've got mutagen ftbfs" or some such so we didn't step on each other's toes. but that would be a lot of noise in another channel... [14:29] mterry: That's not much noise at all. [14:30] mterry: And valuable in -devel, where people who aren't +1mainting might still be working on FTBFSes... [14:30] (Like I currently am...) [14:30] nigelb: I can only watch three anyway (more would make the columns too narrow) [14:30] so I pretty much depend on getting pinged on all the others [14:31] :) Maybe it doesn't need to be separate. I don't have a strong opinion [14:32] doko: Yay, openjdk-6 built. I'm going to do a mass-give back once it's in the archive and all the default-j* stuff is actually installable. [14:34] infinity, maybe wait for java-access-bridge to be built [14:35] infinity: I was waiting for the archive to upload; uploadin [14:35] g [14:36] doko: Sure. [14:36] uploaded login, t1lib [14:36] uploaded tidy [14:37] doko: Are you also keeping the Ubuntu packaging of python2.7 in bzr? [14:37] uploaded watershed [14:38] lool: no, should be syncable [14:38] doko: Do you want to push the ctypes workaround to Debian? [14:38] doko: It doesn't hit Debian right now because the eglibc patches aren't all applied yet, but it would soon [14:38] lool: it already is [14:38] Oh cool [14:38] that was quick :-) [14:40] doko: Ok, syncing python2.7 now [14:40] lool: already is ;-P [14:40] :-) [14:41] seb128: maybe not [14:41] (traffic) [14:47] infinity, seb128: uploaded gtk2-engines, gnome-desktop [14:48] infinity: stuff I had queued has been uploaded; once python2.7 is built we want to give back file and pyicu which seem to fail with the ctypes stuff === Laney is now known as Guest19719 [14:55] lool: We can give those back now. [14:55] lool: I have a home-built version in stage-2. [14:56] lool: (retried) [14:56] infinity: Ok, giving back pyicu [14:56] ah [14:56] Or, you beat me by 2 seconds. :P [14:56] infinity: And file built for some reason; what was the package bdeping on python-magic? [14:56] devscripts [14:56] lool: I already built devscripts. [14:57] infinity: Any other known ctypes issue? [14:57] That was my testcase for the patch. :) [14:57] lool: Not sure. But I'm doing a mass-give-back in a couple of hours anyway. [14:57] (To clear up a bunch of java-related failures) === bladernr_ is now known as bladernr_afk [14:57] infinity: So you got the default-jdk stuff sorted? cool [14:58] I thought that wasn't going to get cleared in practice until the stack starting at t1lib has built [14:58] lool: Well, openjdk-6 built. We'll see in a bit if it's all installable. [14:58] BTW I arranged for 'chdist apt-get precise-armhf build-dep FOO' etc. to work as ubuntu-archive@lillypilly [14:58] which may save you some bandwidth/time [14:59] cjwatson: I'm not allowed to use that but will fix the config [14:59] java-access-bridge needs to be built before giving back java stuff [15:00] doko: *nod*... I'm waiting on it. [15:00] doko: Re: bash, so merging from experimental, or cherrypicking changes? [15:00] oh it's built now [15:01] lool: Already uploade... Yeah. [15:01] I thought some sourceful changes were needed === bladernr_afk is now known as bladernr_ [15:01] oh these were, it's just already all done, cool [15:02] you stop watching IRC for 2 hours and people have uploaded 12 gazillions packges [15:02] lool: yeah you are (now that I've adjustedthe configuration a bit) - HOME=/home/ubuntu-archive ~ubuntu-archive/bin/chdist apt-get precise-armhf build-dep FOO [15:02] cjwatson: chdist armhf> many thanks for that! I had something like that on my list to figure out the armel uninstallables [15:02] pitti: right, it's there for all architectures for precise [15:02] I could set it up for older ones if I could be bothered; archive-reports updates everything in ~/.chdist/ every time the archive changes [15:02] cjwatson: thanks [15:03] I've been going over my prepaid bandwidth limit a bit recently so I've been trying to fix bandwidth-heavy things I was previously doing at home [15:04] if you try using chdist at home, you need to set apt::architectures too [15:04] APT::Architectures { "armhf"; }; in apt.conf [15:04] otherwise apt picks it up from dpkg --foreign-architectures and that breaks against ports.ubuntu.com [15:04] only if you have a multiarch config [15:04] Yes [15:05] who would be crazy enough to still run i386 should really cross-grade to amd64 now! ;-) [15:05] but yes - for clarity, I've edited lillypilly's configs for that [15:05] would it work with multi-arch? [15:05] crossgrading is currently blocked on a new apt [15:06] after that I'll find out what the next blocker is :-) [15:06] geser: Maybe, but ports and non-ports arches use different archives [15:06] (currently apt gets very lost after you've crossgraded dpkg) [15:06] lool: running both thunderbird and firefox on a 2GB machine just doesn't work with amd64. i386 is fine for that [15:06] (fixed in Debian experimental, I think) [15:06] doko: I was just teasing cjwatson, I actually have nothing against i386 :-) [15:07] cjwatson: just wondering, what do you need in the new APT? (wondering if we're both waiting for the same thing :)) [15:08] stgraber: I haven't actually tested but it looks very much like: [15:08] * apt-pkg/deb/deblistparser.cc: [15:08] - M-A: foreign packages provide for other archs, too [15:09] cjwatson: right, we need the same thing then :) I have a apt in my experimental PPA with that patch applied [15:09] ah, I might have a look at that then [15:09] cjwatson: I needed it to be able to install upstart:i386 on armel [15:10] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry [15:10] * dholbach hugs mterry [15:10] dholbach, :) [15:16] stgraber: hm, not clear that helped :-/ [15:16] maybe I'm hitting a subtly different case [15:17] cjwatson: yeah, I think there's still something wrong somewhere as I could get it to work on some systems but not some others, gave the logs to donkult and didn't have much time playing with that again since [15:17] cjwatson: maybe there's something else relevant in that branch other than the commit I cherry picked [15:19] My problem seems to be that Architecture: all packages don't satisfy dependencies of installed :i386 packages after crossgrading dpkg to amd64 and setting APT::Architecture to amd64 [15:20] although perhaps that's a special case of Architecture: all packages needing to be explicitly marked M-A: foreign in general [15:21] ah yes, I decided that wasn't resolvable and instead left APT::Architecture at i386; if I do that, I find that there are lots of unsatisfied dependencies on dpkg (>= foo), despite dpkg:amd64 being installed and marked M-A: foreign [15:21] *that's* what I'd been hoping was fixed in the new apt [15:21] because that's clearly a bug - if it's marked M-A: foreign, foo:amd64 should do just as well as foo for satisfying dependencies on foo [15:26] ah, yeah, different bug then. Mine was with apt not understanding/ignoring provides from M-A foreign packages of another architecture (upstart providing upstart-job and sysvinit in my case) [15:27] so very similar, but not quite identical [15:27] provides versus self-provides :-) [15:28] lool: slangasek: http://people.canonical.com/~serge/qemu-spice-in-linaro.debdiff puts qemu-kvm-spice into qemu-linaro source, and build and runs for me. [15:33] hallyn: I'm a bit surprized that debian/qemu-kvm-spice exists at the time you do the mv; isn't that only created when generating the binary .debs which are created after dh_auto_install is run? [15:37] lool: doesn't dh_dirs create it? [15:39] while creating the usr/bin specified in debian/qemu-kvm-spice.dirs [15:39] hallyn: don't put that in debian/qemu-kvm-spice.dirs ;) [15:39] the .dirs are meant to list any *empty* directories that you need to ship in a package [15:41] stgraber: more breakage with event-based bridging? doh... well, I'm sure you'll get to the bottom of it :) [15:42] slangasek: oh, that wasn't my understanding at all. I thought any dirs I needed to exist to move things into could go into there. [15:42] slangasek: so i should mkdir -p it by hand? [15:42] hallyn: why do you need to? either 'make install' or 'dh_install' should auto-create the dirs for you [15:43]