[05:03] <pitti> Good morning
[07:04] <pitti> 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] <pitti> apachelogger_: also, is there anything new in Kubuntu A1 which should be mentioned in teh announcement?
[08:58] <pitti> 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] <pitti> cjwatson, jamespage: do you have any suggestions how to improve it?
[08:59] <pitti> 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] <pitti> doko: ^ you are looking on c-m a lot, too, any suggestions?
[09:02] <pitti> (fixed title)
[09:04] <pitti> I'll add a legend
[09:40] <jamespage> pitti: that is really useful; what are black arrows?
[09:40] <pitti> jamespage: ah, I'll add that to the legend; these are normal Depends:
[09:41] <pitti> jamespage: http://people.canonical.com/~pitti/tmp/main-promotions.svg updated
[09:41] <jamespage> pitti: I think I should re-introduce a dependency on maven-debian-helper to see how it copes :-)
[09:42] <jamespage> thats what normally causes the java explosion!
[09:42] <pitti> yeah, you should see a huge graph hanging off just one package
[09:42] <pitti> back then it was totally unreadable indeed, and I really wished for a graph like this
[09:42] <infinity> 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] <pitti> now it's usable, but the graph is still better to visualize
[09:42] <jamespage> pitti: agreed
[09:42] <jamespage> one is bound to pop up sooner or later
[09:43] <infinity> pitti: (And I just demoted nscd, not sure how that ended up mismatched)
[09:44] <pitti> infinity: hm, apparently so; it doesn't have armhf in the germinate part, but it does for read_current_binaries
[09:44] <pitti> infinity: will investigate
[09:44] <pitti> cjwatson, jamespage: I also want to improve c-m to point to MIR bugs
[10:21] <Daviey> 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] <pitti> Daviey: oh, you already did that?
[10:22] <pitti> I was just working on integrating this into the reports
[10:22] <pitti> Daviey: for the .txt I'd just add somethign like
[10:22] <pitti> MIR: https://launchpad.net/bugs/12345, Incomplete
[10:22] <pitti> yeah, shut up ubottu
[10:22] <pitti> Daviey: but for the graph we can make the MIRs clickable
[10:23] <pitti> Daviey: we post-process the .txt output in at least one place, but we should get rid of that
[10:23] <Daviey> pitti: i suppose i am lazy, but it provides a pre-canned url to raise one.. overkill?
[10:23] <pitti> Daviey: we can't pre-can them so that ubuntu-mir gets automatically subscribed, but we can certainly do a +filebug link
[10:24] <pitti> not clickable in .txt, but at least c&p
[10:24] <pitti> Daviey: but this is just the first step
[10:24] <pitti> Daviey: once I moved the "diff" processing to something saner, we can just turn it to html
[10:27] <Daviey> cjwatson: Would you consider changing /etc/default/grub : GRUB_DEFAULT=0 -> GRUB_DEFAULT=saved ?
[10:29] <Daviey> Unless i am mistaken, it doesn't cause any change in behaviour, unless people choose to use the saved_entry?
[10:35] <pitti> hah! autogenerated: http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[10:37] <Laney> nice
[10:43] <Daviey> pitti: it is much easier to read.
[10:43] <pitti> I'll integrate MIR bugs there, too
[10:48] <pitti> 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] <apw> pitti, what are you generating the svgs from
[10:50] <apw> (what format)
[10:50] <pitti> apw: component-mismatches generates a dot file
[10:50] <pitti> http://people.canonical.com/~ubuntu-archive/component-mismatches.dot
[10:51] <pitti> then I run that through dot
[10:51] <pitti> apw: i. e. graphviz
[10:51] <apw> yep, met that one :)
[10:52] <pitti> 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] <pitti> although it's a bit like LaTeX: while its default behaviour is reasonable, tweaking the output layout is really hard :/
[10:59] <doko> 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] <doko> ?
[10:59] <pitti> doko: already done for text, doing for SVG
[10:59] <pitti> next report will have it
[11:00] <Daviey> pitti: Should i land my stuff, or have you reproduced it?
[11:00] <pitti> 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] <pitti> let's just HTMLify the main one
[11:01] <Daviey> 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] <Daviey> ho hum, nevermind :)
[11:02] <pitti> Daviey: ah, sorry, wasn't aware of that one
[11:05] <apw> 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] <pitti> 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] <pitti> with a non-interactive test case
[11:06] <pitti> 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] <pitti> sounds perfect to put these two together :)
[11:07] <apw> 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] <pitti> apw: no, we won't hold it for that; we documented it
[11:07] <pitti> workaround: just install again
[11:07] <apw> yeah, fair enough
[11:08] <apw> jibel, in your test rig, are you able to sub in an updated kernel easily ?
[11:08] <apw> seems the first logical step there is to see if it really is write which is returning EINVAL
[11:10] <jibel> 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] <doko> pitti, TheMuso: libatk-wrapper-java-jni needs then needs some symlinks to install into the bootclasspath. is this tested/done?
[11:14] <pitti> Daviey, doko: http://people.canonical.com/~pitti/tmp/main-promotions.svg
[11:14] <pitti> doko: deferring to TheMuso
[11:15] <pitti> Daviey: ah, will add clickable links for +filebug
[11:16] <doko> pitti: instead of approved/unapproved MIR, maybe differentiate between (new/incomplete) and and anything else?
[11:16] <pitti> doko: what's the difference?
[11:16] <apw> 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] <apw> jibel, for the problem in hand i think
[11:16] <Daviey> pitti: nice... new/incomplete does make sense
[11:16] <pitti> doko: you want to differentiate between unassigned and assigned unapproved, too?
[11:16] <Daviey> nah
[11:16] <pitti> doko: I think the difference between "confirmed" and "fixcommitted" is quite important here
[11:17] <pitti> approved == ['In Progress', 'Fix Committed', 'Fix Released']
[11:17] <pitti> I'm happy to handle "wontfix" separately
[11:17] <doko> pitti, well, that's a distinction for one of the shortest periods
[11:17] <pitti> yes, but I'd like to see which ones can be actioned immediately
[11:18] <doko> pitti: but I'd like to see like Daviey's placeholder for suds
[11:18] <pitti> doko: ah, so "incomplete" separately make sense indeed
[11:19] <pitti> but "new" is also for submitted MIRs which are not assigned yet, so I don't think that's very special
[11:20] <doko> well, both new and incomplete show that some action is needed
[11:23] <apw> 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] <pitti> Daviey, doko: done: http://people.canonical.com/~pitti/tmp/main-promotions.svg
[11:26] <pitti> clickable links for filing a bug, and handling "incomplet"
[11:26] <jibel> apw, we start getting a fair amount of duplicates, but for A1 the workaround is fine.
[11:31] <pitti> Daviey, doko: http://people.canonical.com/~pitti/tmp/main-promotions.svg fixed harder now, and split legend
[11:31] <jamespage> pitti: that rocks
[11:31] <pitti> I temporarily set the subunit MIR to "Fix committed" for testing
[11:32] <Daviey> pitti: looks great!!
[11:33] <Daviey> pitti: Now you just need to get the colours approved for brand guidelines. :)
[11:33] <pitti> psychologically they are probably all wrong and unharmonic anyway
[11:33] <pitti> I'm not good at that
[11:33] <pitti> http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[11:33] <pitti> there, MIR status, too
[11:33] <pitti> doko: ^ FYI
[11:34] <pitti> I'll mop this up and announce it properly to ubuntu-archive@
[11:34] <Daviey> \o/
[11:36] <doko> 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] <doko> would be nice if everything can live in ~ubuntu-archive
[11:37] <pitti> doko: marking top-level components> yes, can do
[11:37] <pitti> doko: I just committed it to ubuntu-archive-tools
[11:37] <pitti> doko: ~pitti/tmp was just testing before I committed
[11:38] <pitti> http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[11:58] <jml> barry: it's nearly 2012 and I'm writing new code in Python 2.6. :P
[12:12] <pitti> doko: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt has (MAIN) tags now, ok?
[12:13] <pitti> and http://people.canonical.com/~ubuntu-archive/component-mismatches.svg is fixed to have URLs for every node
[12:14] <pitti> Daviey: ^ so that points out rather nicely that it would make sense to drop the python-coverage b-dep from keystone
[12:15] <pitti> hm, it doesn't link to the keystone MIR, debugging/fixing
[12:16] <pitti> ah, just forgot to run dot, working now
[12:16] <doko> pitti, looks fine
[12:17] <pitti> doko: really gets high time to HTMLify this to get some color and links :)
[12:17] <pitti> but for now, back to alpha-1 stuff
[12:18] <cjwatson> pitti: yeah, I was hoping somebody would do that once it was in lp:ubuntu-archive-tools :)
[12:19] <pitti> it greatly helps indeed
[12:19] <pitti> 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] <cjwatson> pitti: you can rsync those locally if necessary
[12:19] <pitti> right, but they are quite huge
[12:20] <cjwatson> true
[12:20] <pitti> cp component-mismatches cmnew; vi cmnew; ./cmnew ...
[12:20] <pitti> and when done, scp cmnew to my local workstation, bzr commit, and pull on lillypilly
[12:20] <cjwatson> 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] <pitti> admittedly not quite the most elegant way, but avoids downloading all this :)
[12:21] <cjwatson> Daviey: it's possible I was concerned about it not working in some common environments yet
[12:22] <cjwatson> (btrfs, lvm, raid)
[12:27] <pitti> 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] <pitti> 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] <pitti> 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] <pitti> which means..
[12:30] <pitti> 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] <pitti> ... lifting freeze, happy uploading!
[12:31] <infinity> pitti: Changing topics works better when you actually do. ;)
[12:32] <pitti> infinity: argh, I forgot /topic, didn't I
[12:32] <pitti> thanks
[12:34] <infinity> doko: Do you have a bash FTBFS fix in the pipeline?
[12:36] <doko> infinity, yes
[12:36] <infinity> doko: \o/
[12:37] <infinity> 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] <infinity> 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] <ogra_> k
[12:42] <infinity> ogra_: There's a claim that more recent kernels fix it, if you're in a local-experimentation-and-bisecting mood.
[12:42] <ogra_> not really :P
[12:43] <infinity> So, that's a yes?
[12:43] <ogra_> what kernel on what board ?
[12:44] <infinity> linaro kernels on pandas supposedly work.  Ours seem not to.
[12:44] <infinity> But this is all second-hand.
[12:45] <infinity> And it's transient too.
[12:45] <infinity> Given that perl has similar issues, and the last perl build was on a panda and worked fine.
[12:45] <infinity> So, I dunno.
[12:45] <infinity> But I don't like the idea of DoSing our buildds with testsuites either. :P
[13:05] <hrw> hi
[13:05] <hrw> 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] <apw> 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] <apw> jincreator, sorry not for you ...
[13:06] <jincreator> apw: I know. That's OK. :)
[13:07] <ogra_> hrw, are you volunteering ?
[13:07] <ogra_> :)
[13:07] <doko> infinity, I uploaded ossp-uuid and bluez to build without php and gstreamer, will need to revert these changes later
[13:08] <hrw> 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] <hrw> ogra_: https://code.launchpad.net/~hrw/linaro-seeds/multistrap-configs-for-sysroots
[13:08] <infinity> doko: I noticed.  I could have just built them in the stage-2 archive.
[13:09] <infinity> doko: But your way works too. :P
[13:09] <infinity> hrw: All the -dev packages that match ubuntu-desktop would be (A) huge, and (B) probably impossible (there will be conflicts)
[13:10] <ogra_> hrw, did you think about using grep-dctrl ?
[13:10] <infinity> In fact, I know there are conflicts.
[13:11] <hrw> ogra_: instead of grep|cut?
[13:11] <ogra_> yeah
[13:11] <hrw> ogra_: not yet, but may take a look
[13:12] <infinity> 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] <cjwatson> 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:14] <doko> infinity, do you have the test program?
[13:14] <hrw> ogra_: grep is faster then grep-available
[13:14] <jdstrand> pitti: this is very nice: http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[13:15] <infinity> doko: I have the config.log.  Not sure if it left the test around.
[13:15] <hrw> ogra_: 0.006s contra 0.189s
[13:16] <cjwatson> grep is probably faster in raw terms; grep-dctrl is normally a lot more convenient though
[13:16] <hrw> infinity: ubuntu-desktop has two libjpeg libraries: 62 and 8 - I just install libjpeg-dev to solve that
[13:16] <infinity> doko: Oh, duh, the test code is in the log. ;)
[13:16] <infinity> doko: http://paste.ubuntu.com/755981/
[13:17] <hrw> cjwatson: for shell script which has to go though 400-4000 calls of command I prefer faster solution then nicer one
[13:17] <doko> infinity, try to uninstall the multilib libc6-dev?
[13:18] <infinity> doko: It's not installed.
[13:18] <cjwatson> hrw: if that's true then you should probably be refactoring to not require forking 400-4000 subprocesses in the first place.
[13:20] <cjwatson> 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] <infinity> doko: I mean, I'd have just assumed it needs a -I/usr/include/<triplet> or something, but then it works on amd64, so... Confused.
[13:20] <cjwatson> 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] <doko> infinity, works here
[13:21] <infinity> doko: Where "here" is..?
[13:21] <hrw> cjwatson: you are right
[13:22] <infinity> doko: Wait.  I just noticed that it's got a -mfloat-abi=softfp in the command line there.  Nevermind.  Off to dig.
[13:23] <infinity> doko: (Yay for being blind)
[13:24] <doko> AC_MSG_CHECKING(for ARM NEON support in compiler)
[13:24] <doko> _SAVE_CFLAGS="$CFLAGS"
[13:24] <doko> if test "$GNU_CC"; then
[13:24] <doko>   # gcc needs -mfpu=neon to recognize NEON instructions
[13:24] <doko>   CFLAGS="$CFLAGS -mfpu=neon -mfloat-abi=softfp"
[13:24] <doko> fi
[13:24] <doko> AC_TRY_COMPILE([],
[13:24] <doko>                [asm("vadd.i8 d0, d0, d0");],
[13:24] <doko>                result="yes", result="no")
[13:24] <doko> AC_MSG_RESULT("$result")
[13:24] <doko> if test "$result" = "yes"; then
[13:24] <doko>     AC_DEFINE(HAVE_ARM_NEON)
[13:24] <doko>     HAVE_ARM_NEON=1
[13:24] <doko> fi
[13:25] <doko> CFLAGS="$_SAVE_CFLAGS"
[13:25] <doko> AC_SUBST(HAVE_ARM_NEON)
[13:25] <doko> infinity, broken upstream test
[13:25] <infinity> doko: Quite.
[13:25] <doko> and even for armel
[13:25] <infinity> I wish upstreams would stop trying to second-guess my compiler. :/
[13:25] <doko> we don't want to default to neon yet
[13:26] <infinity> No, we really don't.
[13:44] <apw> 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] <apw> jibel, yay right person this time
[13:49] <jibel> 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] <apw> jibel, thanks sounds excellent
[13:50] <doko> apw: iw/crda ping
[13:50] <doko> apw: arm kernel ping
[13:51] <apw> doko, iw/crda> is that the component missmatch between the new crda and iw ?
[13:51] <apw> doko, arm kernel> i've blanked this one, remind me
[13:51] <ogra_> hardfloat ?
[13:51] <apw> ogra_, ?
[13:52] <ogra_> do we have armhf in all kernel packages yet ?
[13:52] <ogra_> as a target arch
[13:52] <apw> ogra_, as far as i know everything is there, but i have nothing to test it on
[13:52] <apw> ogra_, if there are problems with whats in precise tip i am unaware of them
[13:52] <doko> apw, yes, the mismatch
[13:53] <apw> doko, ok i think i forgot to poke tim and have made a note to do so
[13:53] <doko> apw, the kernel issue is bug 861296
[13:53] <ogra_> ah
[13:53] <doko> apw: either make it a suggest, or promote
[13:53]  * ogra_ shuts up stopping to get people on the wrong track
[13:54] <apw> doko, iw/crda> will pass that along
[13:54] <infinity> apw: I believe the build dies in kernel-wedge.  There's a build running on the buildds right now to confirm that.
[13:54] <apw> infinity, ok, as soon as you have a build log poke me so i can look
[13:56] <apw> doko, arm> is that hurting the precise builds, or is it just armhf
[13:56] <ogra_> just ... tsk
[13:56] <ogra_> :)
[13:56] <apw> s/just//
[13:56] <doko> apw, we have some larger java packages which fail to build because of this
[13:57] <apw> doko, ok, seems ppisati is off the air, will poke as soon as i get a chance
[13:57] <doko> and the kernels used are running lucid and oneiric, and precise
[13:57] <ogra_> iirc he is moving houses today
[13:57] <apw> 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] <apw> regardless of sru cycle time
[13:58] <infinity> doko: ppisati was on it, AFAIK, and had GrueMaster and lamont test some kernels.
[13:58] <apw> infinity, yeah looks like the testing was good across the board if the bug is right
[13:58] <doko> infinity, yes, the kernels were tested
[13:58] <infinity> apw: Then upload away? ;)
[13:58] <infinity> apw: We can convince lamont to install from -proposed.
[13:59] <apw> infinity, that assumes I know where the patches you tested are
[13:59] <infinity> apw: Oh.  Yeah.  Then perhaps we wait for ppisati. :P
[13:59] <apw> with ppisati unexpectedly offline (2 days early) i may not have them
[13:59] <apw> i know he was ripped from the new early by his provider so he may not have been prepared yet
[14:00] <infinity> apw: I don't think it's blocking us so urgently that we can't wait for Monday.
[14:00] <infinity> (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] <apw> infinity, ok will see what i can find and make it pp's first job
[14:00] <apw> infinity, ok, and let me know about the kernel-wedge thing
[14:09] <pitti> argh, someone binNEWed python-gi to universe, rendering half of the desktop uninstallable; /me fixes
[14:11] <cjwatson> I fixed that a few minutes ago
[14:11] <cjwatson> 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] <pitti> thanks
[14:27] <mterry> pitti, awesome component-mismatches svg :)
[14:27] <pitti> mterry: :)
[14:27] <mterry> pitti, you should join #ubuntu+1-maint
[14:27] <mterry> That's where the cool kids hang out
[14:27] <seb128> lol
[14:27] <nigelb> heh
[14:27] <seb128> then complain that we have a separate desktop channel
[14:28] <pitti> (argh another channel)
[14:28] <seb128> but then they do sub channel for stuff like maintaining the current distro ;-)
[14:28] <pitti> I desperately try to keep them < 10 so that I can switch to all of them with a key combo
[14:28] <pitti> and don't have to read too much
[14:28] <nigelb> pitti: wow. I have 80-ish. I recently cut down from 150...
[14:28] <seb128> is that so high traffic that it needs to be out of devel?
[14:29] <mterry> 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] <infinity> mterry: That's not much noise at all.
[14:30] <infinity> mterry: And valuable in -devel, where people who aren't +1mainting might still be working on FTBFSes...
[14:30] <infinity> (Like I currently am...)
[14:30] <pitti> nigelb: I can only watch three anyway (more would make the columns too narrow)
[14:30] <pitti> so I pretty much depend on getting pinged on all the others
[14:31] <mterry> :)  Maybe it doesn't need to be separate.  I don't have a strong opinion
[14:32] <infinity> 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] <doko> infinity, maybe wait for java-access-bridge to be built
[14:35] <lool> infinity: I was waiting for the archive to upload; uploadin
[14:35] <lool> g
[14:36] <infinity> doko: Sure.
[14:36] <lool> uploaded login, t1lib
[14:36] <lool> uploaded tidy
[14:37] <lool> doko: Are you also keeping the Ubuntu packaging of python2.7 in bzr?
[14:37] <lool> uploaded watershed
[14:38] <doko> lool: no, should be syncable
[14:38] <lool> doko: Do you want to push the ctypes workaround to Debian?
[14:38] <lool> doko: It doesn't hit Debian right now because the eglibc patches aren't all applied yet, but it would soon
[14:38] <doko> lool: it already is
[14:38] <lool> Oh cool
[14:38] <lool> that was quick  :-)
[14:40] <lool> doko: Ok, syncing python2.7 now
[14:40] <doko> lool: already is ;-P
[14:40] <lool> :-)
[14:41] <cjwatson> seb128: maybe not
[14:41] <cjwatson> (traffic)
[14:47] <lool> infinity, seb128: uploaded gtk2-engines, gnome-desktop
[14:48] <lool> 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
[14:55] <infinity> lool: We can give those back now.
[14:55] <infinity> lool: I have a home-built version in stage-2.
[14:56] <infinity> lool: (retried)
[14:56] <lool> infinity: Ok, giving back pyicu
[14:56] <lool> ah
[14:56] <infinity> Or, you beat me by 2 seconds. :P
[14:56] <lool> infinity: And file built for some reason; what was the package bdeping on python-magic?
[14:56] <lool> devscripts
[14:56] <infinity> lool: I already built devscripts.
[14:57] <lool> infinity: Any other known ctypes issue?
[14:57] <infinity> That was my testcase for the patch. :)
[14:57] <infinity> lool: Not sure.  But I'm doing a mass-give-back in a couple of hours anyway.
[14:57] <infinity> (To clear up a bunch of java-related failures)
[14:57] <lool> infinity: So you got the default-jdk stuff sorted?  cool
[14:58] <cjwatson> I thought that wasn't going to get cleared in practice until the stack starting at t1lib has built
[14:58] <infinity> lool: Well, openjdk-6 built.  We'll see in a bit if it's all installable.
[14:58] <cjwatson> BTW I arranged for 'chdist apt-get precise-armhf build-dep FOO' etc. to work as ubuntu-archive@lillypilly
[14:58] <cjwatson> which may save you some bandwidth/time
[14:59] <lool> cjwatson: I'm not allowed to use that but will fix the config
[14:59] <doko> java-access-bridge needs to be built before giving back java stuff
[15:00] <infinity> doko: *nod*... I'm waiting on it.
[15:00] <lool> doko: Re: bash, so merging from experimental, or cherrypicking changes?
[15:00] <lool> oh it's built now
[15:01] <infinity> lool: Already uploade... Yeah.
[15:01] <lool> I thought some sourceful changes were needed
[15:01] <lool> oh these were, it's just already all done, cool
[15:02] <lool> you stop watching IRC for 2 hours and people have uploaded 12 gazillions packges
[15:02] <cjwatson> 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] <pitti> cjwatson: chdist armhf> many thanks for that! I had something like that on my list to figure out the armel uninstallables
[15:02] <cjwatson> pitti: right, it's there for all architectures for precise
[15:02] <cjwatson> 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] <lool> cjwatson: thanks
[15:03] <cjwatson> 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] <lool> if you try using chdist at home, you need to set apt::architectures too
[15:04] <lool> APT::Architectures { "armhf"; }; in apt.conf
[15:04] <lool> otherwise apt picks it up from dpkg --foreign-architectures and that breaks against ports.ubuntu.com
[15:04] <cjwatson> only if you have a multiarch config
[15:04] <lool> Yes
[15:05] <lool> who would be crazy enough to still run i386 should really cross-grade to amd64 now!   ;-)
[15:05] <cjwatson> but yes - for clarity, I've edited lillypilly's configs for that
[15:05] <geser> would it work with multi-arch?
[15:05] <cjwatson> crossgrading is currently blocked on a new apt
[15:06] <cjwatson> after that I'll find out what the next blocker is :-)
[15:06] <lool> geser: Maybe, but ports and non-ports arches use different archives
[15:06] <cjwatson> (currently apt gets very lost after you've crossgraded dpkg)
[15:06] <doko> lool: running both thunderbird and firefox on a 2GB machine just doesn't work with amd64. i386 is fine for that
[15:06] <cjwatson> (fixed in Debian experimental, I think)
[15:06] <lool> doko: I was just teasing cjwatson, I actually have nothing against i386  :-)
[15:07] <stgraber> cjwatson: just wondering, what do you need in the new APT? (wondering if we're both waiting for the same thing :))
[15:08] <cjwatson> stgraber: I haven't actually tested but it looks very much like:
[15:08] <cjwatson>   * apt-pkg/deb/deblistparser.cc:
[15:08] <cjwatson>     - M-A: foreign packages provide for other archs, too
[15:09] <stgraber> cjwatson: right, we need the same thing then :) I have a apt in my experimental PPA with that patch applied
[15:09] <cjwatson> ah, I might have a look at that then
[15:09] <stgraber> cjwatson: I needed it to be able to install upstart:i386 on armel
[15:10] <mterry> @pilot in
[15:10]  * dholbach hugs mterry
[15:10] <mterry> dholbach, :)
[15:16] <cjwatson> stgraber: hm, not clear that helped :-/
[15:16] <cjwatson> maybe I'm hitting a subtly different case
[15:17] <stgraber> 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] <stgraber> cjwatson: maybe there's something else relevant in that branch other than the commit I cherry picked
[15:19] <cjwatson> 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] <cjwatson> although perhaps that's a special case of Architecture: all packages needing to be explicitly marked M-A: foreign in general
[15:21] <cjwatson> 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] <cjwatson> *that's* what I'd been hoping was fixed in the new apt
[15:21] <cjwatson> 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] <stgraber> 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] <cjwatson> so very similar, but not quite identical
[15:27] <cjwatson> provides versus self-provides :-)
[15:28] <hallyn> 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] <lool> 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] <hallyn> lool: doesn't dh_dirs create it?
[15:39] <hallyn> while creating the usr/bin specified in debian/qemu-kvm-spice.dirs
[15:39] <slangasek> hallyn: don't put that in debian/qemu-kvm-spice.dirs ;)
[15:39] <slangasek> the .dirs are meant to list any *empty* directories that you need to ship in a package
[15:41] <slangasek> stgraber: more breakage with event-based bridging?  doh... well, I'm sure you'll get to the bottom of it :)
[15:42] <hallyn> 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] <hallyn> slangasek: so i should mkdir -p it by hand?
[15:42] <slangasek> hallyn: why do you need to?  either 'make install' or 'dh_install' should auto-create the dirs for you
[15:43] <stgraber> slangasek: yeah, bonding seems fine now, just waiting for some more test results but that only helped discovering that vlan and bridges both have the same problem... I guess I'll just end up making all of them wait for up to a minute or so, checking if the interfaces appear and if not fail (similar to what we have for regular networking since Oneiric)
[15:44] <cjwatson> the other reason to add things to .dirs is if nothing else does the job and you have to install things in debian/rules by hand; for instance if you need to rename a file as part of installing it
[15:44] <cjwatson> generally best avoided, though
[15:44] <hallyn> slangasek: so the dh_auto_build -B spice_build call should do that?
[15:44] <cjwatson> (though even then you could mv it afterwards)
[15:44] <slangasek> stgraber: "never call ifup -a in the boot sequence" - that's where we wanted to eventually be anyway, since /etc/init/networking is merely a fallback; I'm not sure if everything is in place to let us do this, but we should probably make that change early this cycle and work through it
[15:44] <stgraber> slangasek: the clean way would be not to use "ifup -a" EVER and have everything be event based with dependency between the various interfaces (like my bridge depends on a vlan on my bond which depends on a slave being in that bon), but that's tricky to implement
[15:45] <slangasek> hallyn: I wouldn't expect the target directory for the binary package to be created by a call to dh_auto_build; only by dh_auto_install or dh_install
[15:45] <stgraber> slangasek: I think the biggest problem is that there's no clear dependency definition in /etc/network/interfaces, each interface type does it differently
[15:46] <hallyn> slangasek: hm, but i'm following the other examples in that debian/rules, and they do "dh_auto_install -B system-build --destdir=$(CURDIR)/debian/tmp"
[15:46] <stgraber> slangasek: so when adding the first slave to the bond, making it ready to be used, I don't have a way to query what depends on it so I can bring that up, which in turns would bring up something further up the stack, ...
[15:46] <hallyn> well, i can do a run without the debian/qemu-kvm-spice.dirs and see whether it works :)
[15:47] <stgraber> slangasek: my setup at home where I have two interfaces in a bond, then VLANs on top of that bond, then each of these VLANs is a separate bridge is the worst scenario I could think of to test our networking, but it's also what I've been using for years, so I'm probably not alone
[15:48] <lool> hallyn: I would personally install to another dir, e.g. tmp-spice
[15:48] <hallyn> lool: ok, i'd considered that, but figured the others weren't so maybe i shouldn't...
[15:48] <lool> or arrange for qemu to rename the binaries during install, as to not overwrite the other flavors; I think it can install binaries with a prefix or suffix
[15:48] <cjwatson> hallyn: dh_auto_install != dh_auto_build - in particular, dh_auto_build is run as non-root and dh_auto_install typically under fakeroot
[15:48] <cjwatson> quite important to distinguish those two
[15:49] <cjwatson> dh_auto_build should generally not touch or be aware of debian/tmp or debian/PACKAGE-NAME
[15:49] <hallyn> cjwatson: yes, i cut/pasted from the wrong bit of debian/rules, sorry
[15:49] <slangasek> hallyn: I guess that means you got to the bottom of the libnss issue too, right?
[15:50] <hallyn> but, dh_auto_build is building in $(CURDIR)/packagename, essentially
[15:50] <slangasek> hallyn: yeah, try it without the .dirs :)
[15:50] <slangasek> hallyn: no, it's not
[15:50] <hallyn> slangasek: well i never figured out what had happened, so in that sense no.  but sbuild is just working now.
[15:50] <slangasek> not with -B system-build
[15:50] <hallyn> no?
[15:51] <slangasek> dh_auto_build -B system-build builds in the directory system-build
[15:51] <hallyn> i thought that was what i said... ?
[15:51] <slangasek> you said "is building in $(CURDIR)/packagename"
[15:51] <slangasek> which it never does and never should
[15:51] <hallyn> oh, i see, yeah...  i was being sloppy
[15:52] <hallyn> it's not packagename, but there is one for each binary package
[15:52] <slangasek> ah
[15:52] <slangasek> and I read that as debian/packagename, oops :)
[15:53] <hallyn> ok, test build going, shoudl know in about 4 hours :)
[15:54] <infinity> apw: https://launchpad.net/ubuntu/+source/linux/3.2.0-2.5/+build/2965309
[15:55] <lool> ev, mterry: Hmm seems dannf and I both submitted a branch for timezonemap's https://bugs.launchpad.net/ubuntu/+source/libtimezonemap/+bug/897933 FTBFS; sorry about that
[15:55] <apw> infinity, ack
[15:57] <apw> infinity, ahh that is 3.2.0-2.5, which doesn't ahve the fix yet, hrm, once the freeze is done those will get uploaded
[15:57] <apw> infinity, ie. its committed to our tree but not uploaded
[15:57] <infinity> apw: The freeze is done. ;)
[15:58] <apw> infinity, how urgent is that for you, now or a couple of days ok
[15:58] <apw> infinity, wondering if we should upload just that, or with the next up
[15:58] <infinity> apw: I'd love it now, TBH.  I'm two packages away from debootstrap --variant=buildd working.
[15:59]  * apw goes poke peeps
[15:59] <infinity> apw: My hero.
[16:03] <doko> infinity, at-spi needed by java-access-bridge ...
[16:03] <doko> now uploaded
[16:03] <infinity> doko: I was just doing that..
[16:17] <zyga> I'm doing nfsboot and some of the local block devices are not showing up in that case, I tried following initramfs scripts in case of nfs boots but I could not find any traces
[16:17] <zyga> how can I figure out what modules are loaded in a local boot case?
[16:20] <dobey> zyga: lsmod?
[16:21] <zyga> dobey, I cannot easily switch to local boot mode now
[16:21] <zyga> dobey, if I could I would
[16:26] <tgardner> so, thunderbird 9.0 has some real issues with untrusted certificates
[16:28] <lool> hallyn: Your debdiff does build for me though, but I find overwriting the binaries a bit dangerous; the thing I was thinking of seems to be gone, there's an EXESUF but that's a bit hackish; you could install in debian/tmp-spice or even do the same thing for all flavors
[16:29] <hallyn> lool, my test build is still going with i nstalling into spice-tmp.  Sure, I'll move the build-tmp for the others too if you like.
[16:29] <nemo> *sigh*
[16:30] <nemo> why oh why can't the form on https://login.launchpad.net work without javascript?
[16:30] <nemo> you know, so I can log in to reply to bugs from screen + w3m?
[16:30] <nemo> the authentication form doesn't require javascript...
[16:30] <nemo> is just the one that says "yes sign me in" that has no real button for me to click :(
[16:31] <nemo> and if I force a form submit, ignores it presumably due to some JS magic
[16:31] <nemo> maybe that should be a bug.  if only I could file it right now :-p
[16:31] <stgraber> nemo: hmm, FWIW, it works here (just tried with w3m on a lucid system)
[16:32] <stgraber> yes sign me in appeared as a link here I think, anyway I got redirected to Launchpad and it shows me as being logged in
[16:32] <cjwatson> nemo: we don't actually write Launchpad here - perhaps you want #launchpad or #launchpad-dev?
[16:32] <cjwatson> I do remember adding <button> support to w3m for this though
[16:33] <cjwatson> (well, backporting)
[16:33] <sladen> nemo: if you have GPG keys configured, you can send an email
[16:34] <sladen> nemo: new@bugs.launchpad.net
[16:34] <nemo> hm
[16:34] <nemo> stgraber: it's never worked. I've tried on and off for over a year
[16:34] <nemo> stgraber: how odd
[16:34] <nemo> stgraber: I get stuck at:
[16:34] <nemo> If you proceed, the following information will be available to Launchpad:
[16:34] <nemo> Yes, sign me in or cancel
[16:34] <nemo> "Yes, sign me in" is plain text
[16:35] <infinity> doko: Manually bootstrapping java-access-bridge, since it build-deps on itself.  Will be in stage-2 shortly.
[16:35] <doko> infinity, thanks
[16:35] <nemo> stgraber: oh. I see. Yes, sign me in is a "button"  - w3m did not use to support those. Perhaps you have an updated version :D
[16:35] <nemo> stgraber: I approve of button, use it myself, but usually work around it by using X to force a form submit.  hm.
[16:36] <stgraber> nemo: 0.5.2-2.1ubuntu1.2 on Ubuntu 10.04 ("16:32 < cjwatson> I do remember adding <button> support to w3m for this though")
[16:36] <nemo> lol
[16:36] <nemo> nice
[16:36] <nemo> stgraber: I tried that but found w3m source code a bit convoluted
[16:36] <nemo> this is on my gentoo box
[16:36] <cjwatson> nemo: yes, that's missing <button> support - upgrade
[16:36] <nemo> darn :(
[16:36] <nemo> cjwatson: do you have a link to your patch?
[16:37] <nemo> I'll file a bug w/ them and apply it locally
[16:37] <cjwatson> http://paste.ubuntu.com/756124/
[16:37] <nemo> thanks!
[16:37] <nemo> wow. that's rather involved :)
[16:37] <cjwatson> that was for 0.5.2
[16:37] <nemo> cjwatson: no worries. that's stable in gentoo
[16:38] <nemo> cjwatson: BTW. "download as text" appears to have crashed
[16:38] <nemo> although it would probably force me to log in anyway :D
[16:38] <nemo> got a mod python error w/ a stack trace
[16:38] <nemo> http://m8y.org/tmp/temp.txt
[16:38] <cjwatson> http://paste.ubuntu.com/756125/ was for 0.5.3
[16:39] <cjwatson> you have to be logged in for download-as-text to work ...
[16:39] <cjwatson> oh
[16:39] <cjwatson> that looks like something different but I can't help.  #canonical-sysadmin maybe
[16:39] <nemo> m'k
[16:39]  * cjwatson digs out alternative links
[16:40] <nemo> 'sok. I'll just print it to a buffer and clean it up
[16:40] <nemo> cjwatson: otherwise I'm hitting a catch 22 ;)
[16:40] <jibel_> apw, 894768 reproduced on an installed system with this code from ubiquity http://paste.ubuntu.com/756119/
[16:41] <cjwatson> http://bazaar.launchpad.net/+branch/ubuntu/lucid-updates/w3m/view/head:/debian/patches/80-w3m-0.5.2-10-020_button.diff
[16:41] <cjwatson> http://bazaar.launchpad.net/+branch/ubuntu/w3m/view/head:/debian/patches/020_button.patch
[16:41] <jibel_> apw, I use it to copy 3GB of files in a loop. Each iteration, the target directory is emptied.
[16:41] <cjwatson> (0.5.2 and 0.5.3 respectively; has "download file" links
[16:41] <cjwatson> )
[16:41] <jibel_> apw, the test system is a Precise i386 VM running on a 11.10 amd64 host.
[16:41] <jibel_> apw, I'll reboot with your kernel now and run the test again
[16:42] <nemo> cjwatson: gracias
[16:44] <lool> hallyn: Up to you, but might be more consistent to do the same for each separate build; but it's also good to keep the Debian delta to a minimum
[16:45] <hallyn> lool: heh, ok, i'll try to make a decision then :)  (minimizing delta usually wins out in my mind)
[16:49] <jibel_> apw, with your kernel "APW: write -EINVAL" is displayed in dmesg when the error happens. I'll update the report.
[17:04] <SpamapS> oy, more multiarch fail..
[17:04] <SpamapS> [  2%] make[3]: *** No rule to make target `/usr/lib/libbz2.so', needed by `bin/libvtkTeem.so.3.6.3'.  Stop.
[17:06] <cjwatson> SpamapS: vtk is a big bag of fail for hardcoding library paths in its cmake output, IIRC
[17:06] <cjwatson> sometimes a rebuild clears it up ...
[17:10] <micahg> cmake + pkg-config = multiarch goodness
[17:35] <hallyn> slangasek: when i remove qemu-kvm-spice.dirs, debian/qemu-kvm-spice/usr/bin does not exist.  Can I mkdir it in dh_auto_build, or do you see that as wrong too?
[17:37] <broder> slangasek: huh, i had always interpreted .dirs files as being for making up for deficiencies in the package's makefile, especially since dh_installdirs gets run so early in the binary sequence
[17:38] <hallyn> oh, i see.  maybe.  the others do it with "*.install"
[17:38] <slangasek> hallyn: you definitely shouldn't create it from dh_auto_build, which is for *building*, not for *installing* :)
[17:38] <hallyn> sorry again i meant dh_auto_install
[17:38] <slangasek> broder: that's a fair point; I don't frequently tolerate upstream build systems with such deficiencies
[17:39] <hallyn> but if i use qemu-kvm-spice.install then presumably i'll have to make install into debian/tmp after all
[17:39] <slangasek> hallyn: if the directory doesn't exist, are you getting a failure?
[17:39] <slangasek> um
[17:39] <slangasek> hallyn: can I see your debian/rules? :)
[17:39] <hallyn> slangasek: http://paste.ubuntu.com/756195/
[17:40] <hallyn> yes, failure when i mv the binaries into place
[17:41] <slangasek> hallyn: right; I would do this with dh_install --sourcedir
[17:41] <slangasek> hallyn: and a .install file - and no using mv at all
[17:41] <hallyn> slangasek: called from inside override_dh_auto_install?
[17:41] <slangasek> nono
[17:42] <slangasek> hallyn: oh, you're renaming the files, so you would still need the mv; but you can do mv $(CURDIR)/debian/spice-tmp/usr/bin/$$target $(CURDIR)/debian/spice-tmp/usr/bin/$$target-spice
[17:43] <slangasek> hallyn: so the anatomy of a package build effectively has three phases; the build phase, the upstream-install phase, and the binary-package-generation phase
[17:43] <slangasek> dh_auto_install is for the upstream-install phase
[17:43] <hallyn> so i should override_dh_install ?
[17:44] <slangasek> it's optional to have an upstream-install phase that's separate from binary-package-generation, but *if* you're using dh_auto_install, that's what it should be reserved for
[17:44] <slangasek> yes, override_dh_install please
[17:44] <hallyn> and then do i need to call dh_instll in there for each package manually, i guess?
[17:44] <slangasek> it would be:
[17:45] <slangasek> dh_install -pqemu-kvm-spice --sourcedir=$(CURDIR)/debian/spice-tmp
[17:45] <slangasek> dh_install -Nqemu-kvm-spice
[17:45] <slangasek> .
[17:46] <hallyn> ah, -N.  neat.  thanks!
[17:47] <hallyn> the '.' was just there as eof, right?
[17:47] <slangasek> yes :)
[17:49] <hallyn> slangasek: thanks!  i'll start a test build with that.
[17:58] <dantti> cnd: I feel dump :P make install / make modules install is not creating /lib/modules/3.1.0+/... which is probably the cause for my system not to boot (as the initrd image is probably not being created too)
[17:58] <dantti> any ideas what might be wrong? I always just did make menuconfig, make && make install..
[18:01] <cnd> dantti, are you trying to build a linux image from the upstream sources?
[18:01] <cnd> I haven't done that myself in quite some time :(
[18:01] <cnd> your best bet would be to ask in #ubuntu-kernel
[18:03] <dantti> cnd: yes, I'm trying to build the image you've told me
[18:08] <lool> pitti: Last merge of libgksu mentions a 22_increase_gksu_helper_buf.patch but it's not in the source anymore
[18:08] <lool> pitti: I'm remerging it BTW
[18:11] <cnd> dantti, you tried an ubuntu mainline kernel, right?
[18:11] <cnd> just want to be sure
[18:12] <dantti> cnd: sorry I don't understand your question
[18:12] <cnd> dantti, so the kernel team also builds mainline kernels using the ubuntu config
[18:13] <cnd> this is the latest: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-rc2-oneiric/
[18:13] <dantti> cnd: you mean a more recent kernel version? I'm running a stock kernel of 11.10
[18:13] <cnd> when I need to do work like this
[18:13] <cnd> I usually install that latest version
[18:14] <cnd> then I can do the special "make -C /lib/modules/`uname -r`/build M=`pwd`" dance
[18:14] <dantti> cnd: right I see, I'll try installing that..
[18:14] <cnd> this usually works because there often is not much change between the latest upstream rc kernel and the tip of the git tree I'm trying to use
[18:15] <cnd> it's still possible that there's skew that causes it not to work, but much less likely
[18:15] <dantti> sure, and it's much nicer to just build what you need so you don't waste so much time compiling...
[18:35] <bregma> hey folks, I recently was elevated to PPU status for my packageset, and the time has come for me to U one of my P, but I get a rejection due to lack of upload rights... are there more undocumented steps I need to take before I can fulfill my unquiet destiny?
[18:36] <micahg> bregma: looking
[18:39] <micahg> bregma: the team doesn't have upload rights, only cnd, I'm fixing that now
[18:40] <micahg> gah, LP error :-/
[18:42] <micahg> cjwatson: I'm getting: (<Archive at 0x2b5acc2871d0>, 'newPackagesetUploader', 'launchpad.Edit') when trying to add an uploader, any ideas or do I need to bug launchpad, the packageset is owned by the DMB
[18:49] <cjwatson> micahg: don't know, sorry, probably best check with LP
[18:52] <Daviey> cjwatson: Ah, sorry for not responding sooner.  The reason i wanted to differ the grub behaviour, is that i want to mimic a first entry boot.  This is using ipxe.  If ipxe wants to boot from localdisk, then i want to bounce back to grub.
[18:52] <stgraber> micahg: what exactly are you trying to change? the API has been mostly nice with me so far
[18:52] <micahg> bregma: this might take a little while to solve, sorry about that, I can ping you once it's fixed
[18:52] <Daviey> cjwatson: if ipxe is still the default, then it will be a reboot loop
[18:52] <cnd> micahg, how long do you think?
[18:52] <cnd> hour/day/week ?
[18:52] <micahg> stgraber: it's probably an ACL issue, you're on the TB also, so it should work for you
[18:52] <stgraber> micahg: right, what's the change then?
[18:52] <micahg> stgraber: ./edit_acl.py -S precise -P utouch -p ubuntu-utouch-dev -t upload add
[18:53] <bregma> I think I'll go find another hornets nest to stick this stick in to, just to see what happens....
[18:53] <stgraber> micahg: ah, it's one of these broken package sets (duplicate entry)
[18:53] <micahg> stgraber: ah, so if I delete the duplicate it should work?
[18:53] <stgraber> micahg: cnd has twice the upload rights.
[18:53] <micahg> or will it continue to fail
[18:54] <micahg> right
[18:54] <Daviey> cjwatson: So, i was thinking of creating an upstart job that did this, http://pb.daviey.com/dcng/ - resetting on each boot.
[18:54] <stgraber> micahg: nope, you'll get an error from LP if you try to do it
[18:54] <stgraber> Added:
[18:54] <stgraber> Archive Upload Rights for ubuntu-utouch-dev: archive 'primary', package set 'utouch' in precise
[18:54] <micahg> cnd: bregma: all fixed
[18:54] <stgraber> at least the team now has the upload rights, but there's still a LP bug that'll need manual fixing in the DB
[18:54] <cnd> \o/
[18:54] <micahg> stgraber: how did you do it :)
[18:54] <cnd> thanks micahg, stgraber!
[18:54] <cjwatson> Daviey: I understand the reasons, but I'm unsure about the safety of changing the default.  I think it might be better to make it possible to override things in /etc/default/grub without changing the conffile (e.g. a .d directory).  I want to think about that though.
[18:55] <stgraber> micahg: currently, cnd has twice the upload rights and ubuntu-utouch-dev has upload rights too. I can't remove cnd but will ask someone from LP to do it
[18:55] <stgraber> micahg: edit_acl worked for me (only adding stuff, removing stuff fails because of the duplicate)
[18:55] <Daviey> cjwatson: That works for me, i'll leave you to ponder :)
[18:55] <micahg> stgraber: ok, my theory is your DMB+TB superpowers made it work :)
[18:56] <stgraber> stgraber@castiana:~/data/code/ubuntu-archive-tools$ python edit_acl.py delete -P utouch -S precise -p chasedouglas
[18:56] <stgraber> There was a 500 error:
[18:56] <stgraber> NotOneError
[18:56] <stgraber> micahg: that's what happen when you have a duplicate :)
[18:56] <stgraber> time to dig one of my old LP ticket I guess ...
[18:56] <Daviey> cjwatson: This certainly doesn't need to be a wide default for everyone, so a .d works kinda well.
[18:57] <bregma> thank you micahg and stgraber
[19:00] <stgraber> micahg: I re-opened https://answers.launchpad.net/launchpad/+question/177449
[19:01] <micahg> stgraber: thanks, I'm subscribed now
[19:11] <stgraber> slangasek: I think I found why bonding doesn't work in your VM but I'm not really sure how to fix it...
[19:11] <slangasek> oh?
[19:11] <stgraber> slangasek: when eth0 appears, it detects it's part of bond0 so it brings up bond0
[19:11] <stgraber> in the past, it was doing it by running some of the functions manually
[19:11] <stgraber> now instead we create bond0 ourselves which triggers an ifup on it
[19:12] <stgraber> and in turn dhclient
[19:12] <stgraber> even though the slave hasn't been added yet
[19:12] <stgraber> so you're essentially running dhclient on an non-connected interface
[19:12] <slangasek> heh, ok
[19:12] <stgraber> then when it fails, eth0 is joined to the bond :)
[19:12] <stgraber> which explains why running dhclient later on will work just fine :)
[19:14] <slangasek> and of course there's a bootstrapping problem, you can't very well add eth0 to bond0 before bond0 exists - and as soon as it exists, the ifup is triggered
[19:14] <stgraber> now this is most likely because my script now waits for the ifup on bond0 to be done before messing with the slaves, which avoids race conditions but also break dhcp (static IP obviously works fine)
[19:14]  * slangasek nods
[19:15] <stgraber> so an idea would be to mark (touch /run/network/ifenslave.bond) the bond as being ready when it's ready from a sysctl point of view. This shouldn't break the world and if your slave appears within a minute of that, dhcp should succeed
[19:16] <slangasek> I don't have a picture in my head of how that would work
[19:16] <slangasek> but I trust you :)
[19:17] <stgraber> hehe, my problem is that I have way too many pictures of how things should work but can't find one that works for the 6 different types of bond :)
[19:18] <stgraber> (and that doesn't involve getting rid of ifupdown, vlan, bridge-utils and ifenslave and replacing by something that understands dependencies and events)
[19:18] <slangasek> but all of those things are supposed to understand events now ;)
[19:18] <slangasek> (except vlan, which isn't updated for it)
[19:24] <stgraber> slangasek: looks like I was wrong, my code was already marking bond0 as ready just after the sysctl calls are done. The problem is that dhclient starts just before the first slave is added and so uses the MAC address of bond0 at the time, 00-00-00-00-00-00
[19:24] <stgraber> which for some weird reason doesn't seem valid ;)
[19:30] <hallyn> lool: slangasek: http://people.canonical.com/~serge/qemu-spice-in-linaro-2.debdiff   new debdiff hopefully following the suggestions;  builds and works for me.
[19:30] <slangasek> stgraber: right ;)
[19:32] <slangasek> hallyn: please wrap the spice-build handling with a check for the architecture (we don't want to try and fail to build this on !x86), and also mark the build-dependencies as [i386 amd64] in debian/control
[19:32] <slangasek> hallyn: otherwise, looks good - care to submit it as a merge proposal?
[19:33] <hallyn> slangasek: oh, right, guess the arch defs in control won't stop my debian/rules bits :)  will do, thanks.
[19:58] <lool> ScottK: Hey, I suspect you have access to the Debian clamav packaging vcs  :-)  would you mind reviewing the last two changes from the upload I just made?  I would think they should apply to Debian fine -- the man page removal is like just an artifact of a previous upload with generated files: http://launchpadlibrarian.net/86352579/clamav_0.97.3%2Bdfsg-1ubuntu1_0.97.3%2Bdfsg-1ubuntu2.diff.gz
[19:58] <ntr0py> How can i get the configure flags of the installed xserver-xorg-core?
[20:35] <mterry> @pilot out
[20:37] <stgraber> slangasek: do you tihnk it's reasonable to expect a bond interface to always have a slave? I updated the pre-up script for the bond interface to wait up to a minute for a slave to be joined to it. That fixes the dhcp problem and pretty likely most vlan and bridging problems in the process (not all, but the worst ones at least)
[20:38] <stgraber> slangasek: the only case where it'd fail is if you have bond0 defined and marked as auto but your slaves will appear much alter (usb network cards or similar), but then you really shouldn't mark bond0 auto
[20:42] <SpamapS> /usr/lib/python2.7/dist-packages/zope/__init__.py:3: UserWarning: Module argparse was already imported from /usr/lib/python2.7/argparse.pyc, but /usr/lib/python2.7/dist-packages is being added to sys.path import pkg_resources
[20:42] <SpamapS> Is there any reason to have the python-argparse package anymore?
[20:42] <SpamapS> can it just be moved to a provides of python2.7 ?
[20:45] <Riddell> cjwatson: I addedd bug 894805 to my todo list, but I'm ill at the moment so don't know when I'll get to look at it
[20:45] <slangasek> stgraber: hum, but if the bond interface isn't marked "auto", it won't come up automatically when the usb interface starts either?  At least, /etc/init/network-interface.conf would be a no-op for bond0
[20:48] <stgraber> slangasek: well, bond0 would appear but won't get configured indeed, so the slave will be added just fine, but you'll need an extra ifup on it to actually configure it
[20:52] <slangasek> right; aesthetically that doesn't seem the right way to do it IMHO
[20:52] <slangasek> but I also don't have the big picture
[20:54] <SpamapS> slangasek: FYI, I will return to the lvm merge next week. It seriously is the most evil merge ever.
[20:55] <slangasek> heh
[20:55]  * slangasek feigns surprise
[21:06] <ScottK> lool: WIll do.  Thanks.
[21:08] <lool> ScottK: thanks to you!
[21:08] <SpamapS> Ugh.. UDD when upstream has a debian/ dir just does not work.
[21:09]  * SpamapS is still dealing with weirdness 3 releases after they removed it. :-P
[21:09] <mterry> barry, any complaints if I merge protobuf?
[21:11] <barry> mterry: sorry, my brain is a mass of dbus mush.  remind me of the context ;)
[21:11] <mterry> barry, nothing especially.  just you touched it last, and I was about to merge it.  wanted to make sure you weren't about to for some reason
[21:11] <barry> mterry: nope, it's all yours!
[21:11] <mterry> :)
[21:15] <TheMuso> pitti:, doko, not tested yet. I need to find an applicatino I can test with, then I'll try it here.
[21:26] <mterry> Guh, how do I get dpkg-gensymbols to generate nice c++ virtual thunks again?
[21:28] <mterry> seb128, pitti: ^?
[21:29] <seb128> mterry, you don't? ;-)
[21:29] <mterry> seb128, darn it.  It can do them...  But I don't want to manually run c++filt on all my symbols
[21:29] <seb128> the kde packages have some hacks I think, other things like webkit have marked those optional or dropped the .symbols use
[21:30] <mterry> :-/  audiofile is going from C to C++
[21:30] <seb128> but I'm probably not the best placed to talk about cpp, doko or other might know better
[21:31] <mterry> I'll bug them tomorrow about it
[21:34] <Riddell> mterry: see pkg-kde.alioth.debian.org
[21:34] <mterry> Riddell, ok!
[21:35] <mterry> specifically http://pkg-kde.alioth.debian.org/symbolfiles.html it looks like
[21:35] <Riddell> yes
[22:34] <doko> Daviey, I honestly don't want to backport the lcms2 changes to openjdk-6
[22:39] <Daviey> doko: i'm lacking context....
[22:39] <doko> Daviey, you just set a milestone for a report
[22:40] <Daviey> doko: i bumped non Fix-Released milestones  from precise-alpha-1 to precise-alpha-2, that is all.
[22:41] <dobey> anyone know why quilt would think a patch is applied, which is not applied?
[22:42] <RoAkSoAx> dobey: because it's applied but there's no info in .pc/
[22:42] <RoAkSoAx> dobey: you'll probably have to reverse apply the patch manually
[22:42] <dobey> no, it is not applied; and there is no .pc
[22:42] <RoAkSoAx> and then re-apply it with quilt
[22:42] <dobey> https://launchpadlibrarian.net/86210138/buildlog.txt.gz
[22:42] <Daviey> doko: tkamppeter set the alpha-1 milestone, and it was assigned to him.. I would discuss it with him.
[22:43] <dobey> this is happening trying to build from upstream trunk and nesting a debian/ dir inside
[22:43] <dobey> running the same command locally, it says "No patches applied"
[22:43] <dobey> or "No patch removed" rather
[22:44] <RoAkSoAx> dobey: try to reverse apply the patch first, "patch -R < debian/patches/etcetc" and then do the quilt stuff
[22:46] <dobey> RoAkSoAx: "Unreversed patch detected! Ignore -R? [n]"
[22:46] <dobey> RoAkSoAx: the patch is not applied :)
[22:46] <RoAkSoAx> dobey: then, the patch is not applying cleanly: "Patch 05_hide_on_quit.patch does not remove cleanly (refresh it or enforce with -f)"
[22:46] <RoAkSoAx> dobey: you'll need to refresh it
[22:46] <RoAkSoAx> dobey: I can't say for sure until I have the source of what you are trying to do :)
[22:46] <dobey> [dobey@lunatari:rhythmbox]: patch -p1 < debian/patches/05_hide_on_quit.patch
[22:47] <dobey> patching file shell/rb-shell.c
[22:47] <dobey> patching file shell/rb-shell.h
[22:47] <dobey> it applies perfectly cleanly, and i did already refresh it
[22:48] <dobey> RoAkSoAx: and applying all the patches with quilt, then un-applying them with quilt, works perfectly fine locally
[22:49] <dobey> and i don't think debbuild is applying them before running that quilt command
[22:49] <RoAkSoAx> dobey:  I'll have to take a look at it to be able to help you further
[22:50] <dobey> RoAkSoAx: https://code.launchpad.net/~ubuntuone-hackers/+recipe/rhythmbox-dailies is the recipe i'm trying to build
[22:52] <RoAkSoAx> dobey: can you point me to a .dsc please?
[22:54] <StevenK> dobey: The first thing a recipe build does is run make clean, it is attempting to remove the patches and failing
[22:57] <dobey> StevenK: yes, debuild -S does this, and it works fine locally;
[22:57] <dobey> RoAkSoAx: http://people.gnome.org/~dobey/rhythmbox/
[22:58] <doko> qt4-x11 finally building on armhf ... good night
[22:59] <StevenK> dobey: I wonder if your bzr branch is missing some files that you have locally
[23:00] <dobey> no
[23:01] <dobey> everything is there
[23:07] <RAOF> @pilot in
[23:44] <dobey> RoAkSoAx: find anything?