[03:08] * ScottK shakes fist at slangasek. [03:08] Multi-arching qt4-x11 broke python-qt4 builds too. [03:08] ScottK: So you'd prefer qt4-x11 wasn't multi-arch? :-) [03:09] I'd prefer I'd understood what was going to happen better before I approved the FFe. [03:09] StevenK: Are you in the mood for some removals? [03:10] I'm *always* in the mood for some removals [03:10] hehe [03:11] Excellent. [03:11] ScottK: I'm about to hit up lunch, so toss me a list and I'll look soon [03:11] StevenK: OK. [03:13] Bug #82914 (pgdesigner), then you can NBS gambas2-gb-qt-kde and gambas2-gb-qt-kde-html, then Bug #794513 gets rid of kdewebdev-kde3 and kdelibs. [03:13] Launchpad bug 82914 in Ubuntu "Huge noise in sound" [Undecided,Invalid] https://launchpad.net/bugs/82914 [03:13] Launchpad bug 794513 in kdewebdev-kde3 (Ubuntu) "Please remove kdelibs and kdewebdev-kde3 from the archive" [High,Confirmed] https://launchpad.net/bugs/794513 [03:13] StevenK: ^^^ [03:13] Oops. [03:13] Bug #829149 [03:13] Launchpad bug 829149 in pgdesigner (Ubuntu) "Please remove pgdesigner source and binary from onerici" [Medium,Confirmed] https://launchpad.net/bugs/829149 [03:13] That one. [03:14] ScottK: Okay, I've made a note [03:14] Great. Thanks. [03:18] StevenK: Never mind. slangasek beat you to it. [03:18] (sorry for the double request, I didn't realize he was around) [03:18] StevenK: I've got a list in the ~ubuntu-archive queue if you're removal happy :) [03:19] *feeling removal happy :) [03:20] As he says, that's his usual state. [03:20] slangasek: I filed Bug #829165 for your reading enjoyment (and hopefully you fix it). [03:20] Launchpad bug 829165 in python-qt4 (Ubuntu Oneiric) "FTBFS due to multi-arching of qt4-x11" [High,New] https://launchpad.net/bugs/829165 [03:20] and it's Friday for him, the perfect time :) [03:44] ScottK: heh; which would you like first, wxwidgets or python-qt4? :) [03:44] slangasek: python-qt4. [03:44] ok, queued [03:45] That's a package I actually care about as opposed to a package I happen to receive bugmail for ... [03:45] * slangasek chuckles [03:45] StevenK: There's also Bug #829175 if you still want a removal. [03:45] Launchpad bug 829175 in kdegames (Ubuntu Oneiric) "Please remove kubrick and ksudoko binaries on armel only" [High,Confirmed] https://launchpad.net/bugs/829175 [03:46] slangasek: you around for another 10 minutes? [03:46] micahg: actually no... but StevenK is? [03:46] slangasek: ok, no problem [03:47] ScottK: hmm, this is after sip4 is fixed or not? [03:47] slangasek: Not. I didn't get a chance to look at sip yet. [03:47] ScottK: because python-qt4 is the package that led me to the sip4 regression... unrelated to multiarch ;) [03:48] Hmmm. [03:48] Except that particular build failure is due to a multiarch path. [03:49] I broke qscintilla2 in Debian and it got to Testing to that got pushed on the stack ahead of sip4. [03:49] to that/so that [03:49] ScottK: yeah, I dug into it thinking it might be multiarch, but it's definitely sip4 [03:49] Crap. OK. [03:50] built fine with the previous upstream version [03:50] Glad I didn't upload that sip4 to Debian yet then. [03:50] Grumble. Please assign that one to me then. === plars_ is now known as plars [04:03] StevenK: would you happen to be back from lunch? [04:04] micahg: Mmmm? [04:04] StevenK: can I get you to publish a security update for me from a PPA? [04:04] micahg: Which PPA? [04:04] I got 3 out of 4 sources to work, but the last one has too many binaries [04:05] StevenK: ubuntu-mozilla-security (public) [04:06] micahg: Firefox 6, I guess? [04:06] StevenK: I need firefox 3.6.20+build1+nobinonly-0ubuntu0.10.04.1 to lucid-security [04:06] StevenK: nah, slangasek too care of that for me on Tuesday [04:06] *took [04:10] micahg: Done. [04:10] StevenK: just that one, right? [04:10] micahg: Yes, just that one. [04:10] StevenK: thanks! [04:18] Good morning [04:19] ScottK: If you're still around, pgdesigner, gambas2-gb-qt-kde{,-html} and kubrick purged as requested. [04:20] ScottK: slangasek beat me to removing kdelibs, and I can't find ksudoko at all. [04:26] StevenK: Can't "find" it? [04:26] ksudoku | 4:4.6.0-0ubuntu2 | natty | armel [04:26] ksudoku | 4:4.6.0-0ubuntu2 | oneiric | armel [04:26] ksudoku | 4:4.6.2-0ubuntu2 | natty | amd64, i386, powerpc [04:26] ksudoku | 4:4.7.0-0ubuntu2 | oneiric | amd64, i386, powerpc [04:26] Ah, ScottK can't spell [04:26] And you don't autocorrect well, apparently. ;) [04:27] I don't play sudoku, so meh :-P [04:27] that typo actually makes for a rather comical command :) [04:27] And you've somehow missed millions of people referring to it for the last decade? :) [04:28] micahg: I assume it's a KDE command for invoking toolchain builds? [04:28] infinity: Not missed; ignored. [04:28] infinity: something to that effect ;) [04:42] slangasek: it must have stung your heart to touch ia32-libs again [04:43] pitti: ia32-libs has taken a piece of every every soul that's touched it over the years. [04:46] slangasek: oh, BTW: flash working like a charm here now [05:09] pitti: nah, I got to take an axe to ia32-libs, that was fun ;) [05:09] my only regret is that I couldn't cut more out [05:13] There seem to be some dependency issues remaining; I didn't get libnss3:i386 or libcurl3:i386 installed automatically. Once they _were_ installed, though, hurray! [05:15] hmm, how did you install? [05:16] libnss3 and libcurl3 are definitely in the dep list, so that's pretty odd [05:19] ia32-libs. the reverse horcrux. [05:21] hah [05:21] kees: It just won't die? [05:22] slangasek: I just update-managered. [05:22] slangasek: I didn't do anything fancy to install. [05:22] RAOF: but then, wouldn't you still have had flashplugin-installer:amd64 installed? I haven't nuked that yet... [05:23] StevenK: well, just going off what infinity said. if it steals a little of everyone's soul. maybe I should say 'super horcrux' instead. [05:23] Haha [05:23] slangasek: Yes, indeed I have got flashplugin-installer:amd64 installed. [05:24] slangasek: And it wants libnss3, which no longer appears to be in ia32-libs? [05:24] RAOF: right - switching to flashplugin-installer:i386 should have pulled in the libs for you (and allow ia32-libs to be removed) [05:24] yes, it's not in ia32-libs anymore because flashplugin-installer:amd64 is on its way out [05:24] Ah, ok. It's just currently broken :) [05:25] Transitionally broken. [05:25] yep - I'll have it gone this week [05:26] slangasek: So ia32-libs will exist in oneiric release, a shadow of its former self, or utterly purged? [05:26] slangasek: can packages depend on other arch versions of themselves? [05:26] StevenK: will still exist. if you want to expedite its irrelevance for p, please provide multiarch patches for libxml2 and unixodbc in Debian :) [05:28] micahg: nope. So maybe flashplugin-installer would want to become a transitional package? [05:28] there are a couple ways it could work, I mean to play to see which gives the best behavior [05:29] StevenK: also, libao [05:29] slangasek: well, if you want to play with it, you could use the flashplugin-nonfree transitional package to depend on the i386 installer and have the flashplugin-installer:amd64 depend on it [05:30] micahg: by making flashplugin-nonfree an i386-only package? heh, twisted but it would work [05:32] slangasek: well, you still need the amd64 package to depend on nspluginwrapper, still not sure how the dependency chain would work [05:32] that's assuming we don't just conclude nspluginwrapper should be pulled in on i386 too [05:33] ah, right, you suggested that before and it sounded like a good idea [05:34] but yes, flashplugin-installer:amd64 Multi-Arch: same, depends: flashplugin-nonfree+nspluginwrapper; flashplugin-nonfree:i386 Multi-Arch: foreign Depends: flashplugin-installer; flashplugin-installer:i386 Multi-Arch: same would do the job [05:34] and make people go cross-eyed ;) [05:35] slangasek: I thought you said you can't have the same package installed on 2 archs? [05:35] s/on/from [05:35] you can if it's marked Multi-Arch: same [05:35] ah, perfect then, that's what I was thinking :) [05:39] oh dear [05:39] Suggests: xfs (>= 1:1.0.1-5) [05:49] slangasek: it's just a suggests, maybe drop it for now if there's no time... [05:49] micahg: the "oh dear" was that it suggests it at all, given that nothing uses xfs anymore :) [05:50] ah [05:52] uhhhh .... XFS is one of the very popular choices among DBAs for data partitions [05:52] mneptok: apt-cache show xfs ;) [05:52] slangasek: oh, *package* XFS [05:53] slangasek: why are you not at LinuxCon? it's just up the road ... [05:53] mneptok: too much travel this summer already [05:53] * mneptok went to dinner with Canonicalians on Monday. 'twas fun. [05:54] all travel and no work makes ia32-libs a something-something [05:54] "bloated piece of crap" [05:55] "still a scary solution?" [05:58] micahg: works as expected with dpkg; I'll check a bit later what happens with update-manager, before uploading [05:58] slangasek: very cool, thanks [06:00] micahg: actually, just pushed to my multiarch ppa, so you're welcome to test too [06:01] slangasek: maybe after I get this USN out :) === Quintasan_ is now known as Quintasan [06:05] pitti: according to the test rebuild, qdox requires jmock, which got demoted [06:06] doko_: ah, qdox wants to go to universe as well, doing [06:06] http://people.canonical.com/~ubuntu-archive/component-mismatches.txt [06:06] I'll clean that up a bit [06:06] ant-contrib, antlr3, etc. [06:06] seems all obsolete [06:07] ok, thanks [06:09] oh, portmap wants to go to universe, too? [06:10] ok, most stuff in "source main->universe" done, except for the ones which should be checked again [06:10] pitti: hmm, there were some things there which I promoted ... so [06:12] at least protobuf-c and x264 [06:12] ah, I can put them back then [06:13] but I guess at some point an AA cleanup will demote them again until they get an rdepends [06:13] icc-profiles-free [06:13] tkamppeter__, ^^^ [06:13] I kept that one [06:13] also icc [06:14] and not sure if we should keep maven-ant-helper for now, there is a spec to go to maven3 [06:14] jamespage, ^^^ [06:14] we can promote it back when needed [06:15] it was in main before, so that doesn't need any process [06:17] once ubiquity drops its cheese b-dep, c-m should look a lot more useful again [06:21] micahg, isn't there a reason that ssmtp has a `fakesync' in the version? [06:21] doko_: I checked and apparently not... [06:22] it was originally due to .bz2 issues, I think those have been fixed, but if not, I"ll upload manually [06:22] pitti, icc-profiles needs perhaps a direct seed in ubuntu-desktop. [06:23] err, that one is in multiverse [06:23] can gjs get pushed through the NEW queue? [06:24] doko_: in theory, gpac could be dropped instead of MIRd depending on what siretart wanted to do with it [06:25] micahg, well, let him sort it out [06:26] doko_: right, that's why I filed the bug and subscribed him :), I guess I should've been clearer in the descrption there [06:27] oh right, x264 drags gpac [06:27] well, we'll loose quite important functionality with that === tkamppeter__ is now known as tkamppeter [06:31] I'll have to look at why gpac is in multiverse in the first place. [06:31] siretart: it's in universe I thought [06:31] ah, I misread the backlog [06:32] hm. we have a package for debian more or less ready, I wonder why we haven't uploaded it yet: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/gpac.git [06:33] siretart: what does it use xulrunner for? [06:33] tbh: no idea [06:35] siretart: ah, it seems to just need mozjs [06:41] ScottK, please add the ftbfs tag to new build failure reports [06:51] ScottK, will you do something with your teeworlds backport? still wants a newer bamf, and shows up on the buildds every hour or so [06:52] tkamppeter: icc-profiles sounds like something that should be a dependency of something [06:53] pitti, then I suggest that colord or the color management part of g-c-c should depend on icc-profiles. [06:53] pitti, can you have a look at bug 829205? It is really annoying for developers.\ [06:53] Launchpad bug 829205 in Ubuntu "multiarch environment makes testing of new package version for developers very awkward" [Critical,New] https://launchpad.net/bugs/829205 [06:53] tkamppeter: hm, icc-profiles is in multiverse, so actually we can't seed or depend on it [06:54] pitti, s/icc-profiles/icc-profiles-free/ [06:54] tkamppeter: I'm afraid that's a little outside of what I have time to do.. [06:55] tkamppeter: ah, right; i-p-free could be a recommends: of colord? [06:55] or whichever package is actually using it [06:55] we only seed top-level applications [06:55] pitti, yes that would be OK,. [06:55] RAOF, hi [06:55] I'm off for an hour or so, have an appointment [06:56] pitti, which package for bug 829205? [06:56] tkamppeter: Hi. [06:56] Launchpad bug 829205 in Ubuntu "multiarch environment makes testing of new package version for developers very awkward" [Critical,New] https://launchpad.net/bugs/829205 [06:56] RAOF, can you add a Recommends: icc-profiles-free to colord? [06:56] tkamppeter: hm, dpkg probably [06:56] pitti, thanks. [06:56] tkamppeter, pitti: Way ahead of you. Let me hunt down my bug for that :) [06:56] tkamppeter: Certainly. [06:57] tkamppeter: I'll finish looking into the run-as-system-user patch and such, too. [06:58] tkamppeter: Oooh, actually, that's not the bug I'm thinking of; it's subtly different.\ [06:58] But the solution is to build i386 packages, too. [06:58] bug #827950 is the one I was thinking of (which you'll hit if you *do* build i386 and amd64 packges) [06:58] Launchpad bug 827950 in dpkg (Ubuntu) "Multiarch: dpkg gets confused when installing new packages with the same version" [Undecided,Won't fix] https://launchpad.net/bugs/827950 [06:59] RAOF, so installation of an amd46 build environment (build-essential) should pull the i386 build environment and then every package should be actually built twice? [07:00] tkamppeter: Well, no. But you'll need an i386 build chroot; either pbuilder or sbuild. Perhaps they should have their defaults changed to automatically build both i386 and amd64, though. [07:01] Subscribe somebody else ... ev ... Please enter at least three characters ... this is INSANE! [07:02] RAOF, or does this mean that I have to develop and test in an i386 environment? [07:02] slangasek, hi [07:03] tkamppeter: It means that, if the packages you are touching are multiarched, you will need to build both amd64 and i386 packages. If you have the i386 package installed. [07:03] doko_: that doesn't look like it's been filed yet [07:03] tkamppeter: So, either don't have the i386 package installed, or build both amd64 and i386 packages. [07:04] micahg, what? [07:04] RAOF, can I remove the i386 stack from my amd64 system? And if so, how to proceed? [07:04] tkamppeter: apt-get remove $PACKAGE:i386 [07:04] doko_: against launchpad [07:05] tkamppeter: Unless you've got something critical (currently, the only possible candidate is flash) which depends on the i386 package, that'll work just fine. [07:05] RAOF, and this for 100s of libs one-byone? [07:06] RAOF, how do you do your package development and testing? [07:07] tkamppeter: The only multiarch package I touch is mesa and its dependencies. I just build both i386 and amd64 packages and install them side-by-side. [07:07] tkamppeter: If you care about libcups2, either remove libcups2:i386 or build an i386 libcups2 binary. [07:08] (Obviously, as well as your amd64 binary) [07:08] RAOF, this means you have to do all test builds in a chroot, like pbuilder and always sttart the two builds in parallel and wait them to finish ... [07:08] tkamppeter: That's correct, although I do test builds (that I might possibly want to _install_ ) in a chroot anyway. [07:09] tkamppeter: Or, you can remove libcups2:i386; there's probably nothing interesting depending on it. [07:09] good morning [07:11] RAOF, correcting this by removing packages removes acroread and flash. [07:13] tkamppeter: Then you'll need to build i386 packages as well as amd64 packages. [07:13] tkamppeter: I agree that's a bit awkward. [07:32] pitti, doko: I think maven-ant-helper could be demoted for the time being - but please can antlr3 remain in main - see bug 814819 and bug 828816 [07:32] Launchpad bug 814819 in antlr3 (Ubuntu) "[FFE]Update to antlr3 version 3.2" [Low,Confirmed] https://launchpad.net/bugs/814819 [07:32] Launchpad bug 828816 in jython (Ubuntu) "Update to jython version 2.5.1" [Undecided,New] https://launchpad.net/bugs/828816 === chrisccoulson_ is now known as chrisccoulson [07:48] tkamppeter: hey there - has RAOF answered your question already? === doko_ is now known as doko [07:49] jamespage, can you seed it, or else pitti will demote it again ;p [07:49] can't approve FFE's [07:50] doko: working on those bugs today [08:07] jamespage: do we really need to seed it? seems like the kind of package that really ought to be a build dep, not a top-level app [08:07] jamespage: we can re-promote it once something pulls it in [08:07] pitti: jython will pull it back in once its upgraded so no it does not need seeding [08:08] ah, good === smb` is now known as smb [08:25] doko_: has my username uncovered a bug in LP? [08:27] seb128: I did, tis what I meant by the other stuff I'd take care of in the morning. [08:27] it's too short :) [08:27] ev: good morning [08:27] good morning, pitti! [08:27] ev: hey, ok [08:27] on it now [08:27] thanks [08:27] ev: well done on landing the ubiquity gtk3 version btw! [08:28] thanks, that was quite the battle [08:28] there's still a massive bug in the css handler [08:28] keeps segfaulting randomly [08:28] hope to get to the bottom of that today or monday [08:28] ev: yeah, congrats! I'll try it with the new pygobject on today's live CD (assuming that it builds), and fix up remaining stuff if needed; but by code inspection it shoudn't cause trouble with the new version [08:29] that might actually help, pygobject 2.90 turns a lot of these previous segfaults into proper exceptions [08:29] yay [08:29] pitti: that's grand news [08:29] do you know offhand if they fixed the exceptions being raised in a different context issue? [08:30] I checked the bug yesterday and it wasn't closed, but perhaps it was fixed with some other change [08:30] I don't know about that, I'm afraid [08:30] no worries, I'll have a look [08:31] ev: if you want to test with the new version, it's in https://launchpad.net/~ubuntu-desktop/+archive/ppa [08:32] ev: but beware, there are some caveats (bug 828751) [08:32] Launchpad bug 828751 in pygobject (Ubuntu) "[FFE] update pygobject to 2.90.1" [Undecided,Confirmed] https://launchpad.net/bugs/828751 [08:33] ev: I had to promote the timezone package, MIR was missing :-/ [08:34] ev: I made a task for myself in bug 829186 to check ubiquity with the new pygi, FYI [08:34] Launchpad bug 829186 in ubuntuone-control-panel (Ubuntu) "Mixes static and GI library bindings" [High,Triaged] https://launchpad.net/bugs/829186 [08:34] ev: now I know why you don't get subscribed to any bug reports ;) [08:42] hallyn: which version of lxc do you want backported? We have to support the upgrade paths so the backport will need to go to the intervening releases too. [08:44] hallyn: So, what we need to approve the backport is you to state that it builds, installs and runs without further changes on those releases [08:52] ev: is cheese still required in main? [08:52] doko: nope! [08:56] ev: so I can demote it from supported-desktop-extra? [08:56] doko: please do [08:58] \o/ [08:58] ev: nice work, glad that's finally landed :) [08:58] me too [08:58] and shouldn't you be sleeping? [08:59] that's debatable [08:59] :) [09:01] unseeded [09:05] ev: I had a session scheduled with my GSoC student actually; people in Ireland apparently keep nearly as funny hours as in London :) [09:07] heh, nice [09:10] doko: Ready to be super happy? https://launchpad.net/ubuntu/+source/psyco/1.6-2ubuntu1 <-- a Recommends of ajaxterm. [09:10] going to bump it down to suggests, due to being locked into python2.6 [09:27] ogra_: around? if you could please push your livecd-rootfs changes to lp:livecd-rootfs, that'd be great - I want to work on livecd-rootfs a bit today [09:34] cjwatson, hmm, i thought i had [09:34] * ogra_ checks [09:35] hmm, the branch is up to date [09:35] * ogra_ wonders whats wrong here [09:38] what does 'bzr info' say? [09:38] lp:livecd-rootfs here only has 2.26 [09:38] the archive has 2.27 [09:39] yeah, got it ... one sec [09:40] there you go, sorry the branch was on a different machine [09:47] ogra_: ah, right - thanks [09:47] (checking terminal prompts helps sometimes :) ) [09:53] http://people.canonical.com/~ubuntu-archive/component-mismatches.txt [09:53] Daviey: there seem to be some nova related MIRs missing [09:53] much better [09:53] Sweetshark, ^^^ MIR's for translate-toolkit dependencies missing [09:54] cjwatson: FYI, current CD buidl failure due to python-gmenu missing is being handled, just needs a s-c upload now [09:55] doko: the -carrot induced ones i'm holding out on, as there is work to get rid of carrot. [09:55] ScottK, ^^^ MIR for kdesvn missing? [09:55] pitti: yeah, had already checked software-center bzr for that :) [09:55] doko: socat i raised an intial one, and asked zul to finish [09:55] cjwatson: ah, way ahead of me :) [09:56] doko: and -psyco, see above. I have someone sorting that out right now. [09:59] doko: The recommended demotion of powernap, i am investigating if we actually still have a reason to keep it in main. [09:59] * Daviey notes that components-mismatch would be more useful if it linked to [MIR] bugs. [10:00] Daviey, no dependency [10:00] doko: uh? [10:00] Daviey, it appears in demotions, because it's not referenced in main [10:00] Daviey, I suppose cjwatson would accept a patch ;) [10:00] doko: Yes, i'm trying to find out if we need to make it a dep or seed it seperately, or let it fall through. [10:01] cjwatson: Where is the code which generates components-mismatch, it's not part of germinate iirc? [10:02] Daviey: it's in ~lp_archive/dak/ on cocoplum, don't remember whether it's public [10:03] I'm not sure how it would go about knowing where the MIR bugs were though ... [10:03] cjwatson: bugs with prefix title [MIR] or ubuntu-mir subscribed ? [10:05] Daviey: I think all open bugs against the source package with ubuntu-mir subscribed is a very good approximation; there are seldomly more than one of those [10:05] and if so, listing both of them wouldn't hurt [10:09] I'll take a sniff at doing that. [10:10] It could even just link to https://bugs.launchpad.net/ubuntu/+source//+bugs?field.subscriber=ubuntu-mir [10:10] pitti: The problem is that some ~ubuntu-mir's work flow seems to involve un-subscribing if the MIR isn't ready, which would hide the inprogress report. [10:10] Daviey: oh, is it? back then we just set them to incomplete [10:10] Laney: is that your workflow? [10:11] I'm not on the MIR team [10:11] It's a long link, but you won't have to actually talk to launchpad to generate the list. [10:11] hmm, sorry - i'm getting confused between ubuntu-mir and ubuntu-release [10:11] but unsubscribing sounds weird [10:11] soren: That is easier to implement, but doesn't give a quick reference if the url links to an empty set. [10:12] Daviey: Sure. [10:12] Daviey: ...which is roughly as useful/useless as a missing reference (which is what you'd get if you tried to find this info ahead of time with launchpadlib or whatnot), isn't it? [10:13] doko: I know, is on my list === Pendulum_ is now known as Pendulum [11:39] cjwatson, i have noticed that the new live-build environment is not inluding the overlayfs.ko onto the casper initramfs. I've tested adding that .ko is enought to successfully enable its use. I am wondering what the process is for fixing live-build given its odd nature [11:41] apw: I'd be surprised if it had anything to do with live-build [11:41] surely it's up to the casper package to include what it wants [11:42] lp:ubuntu/casper hooks/casper, add another manual_add_modules line somewhere there [11:42] it already has them for unionfs/aufs/blah [11:43] * apw checks, i thought there was a list in live-build too, but maybe i am mistaken which its using [11:43] shouldn't be [11:43] it's a few layers removed [11:44] cjwatson, cool then i must be mistaken, and i've lost the tmp dir which had my work... grrr [11:44] well, OK, there's LB_UNION_FILESYSTEM in there, but all that does is pass a kernel parameter [11:44] and that isn't used in our builds [11:51] cjwatson, ok cool, as simple as this it appears: lp:~apw/ubuntu/casper/oneiric/overlayfs-module [12:04] apw: LGTM, thanks - merged and uploaded [12:05] cjwatson, thanks === ximion2 is now known as ximion [12:09] tkamppeter: thanks for the continuous fixing of the ppd-updating patch. :-) Now I don't think your fixes on foomatic-db-engine were really necessary (but will fix in the next updates). [12:11] nspluginwrapper: no appropriate viewer found for /usr/lib/flashplugin-installer/libflashplayer.so [12:11] dpkg: error processing flashplugin-installer (--configure): [12:11] subprocess installed post-installation script returned error exit status 1 [12:11] is there anyway around that for amd64? === ximion_ is now known as ximion [12:13] doko: AFAIK there's no intent to put kdesvn in Main. I'll have to see what's up this time (this isn't the first time). [12:14] doko: re teeworlds and bamf it's an LP bug. [12:14] StevenK: Thanks. [12:17] ScottK: kdesvn appearing in component-mismatch is caused by the kdesdk ftbfs on powerpc [12:17] Ah. [12:17] debfx: Thanks. [12:18] are we aware that PPA builds (at least) are dropping to CHROOTWAIT apparently due to a glibc detected memory corruption in sudo [12:18] unfortunately I've no access to hardware to work on that one. [12:18] asac: could you please have a look at my patch for bug #750554? [12:18] Launchpad bug 750554 in ntrack (Ubuntu) "0.14: nl modules are not linked with libntrack even if they use symbols from it" [High,Confirmed] https://launchpad.net/bugs/750554 [12:22] apw: I asked #is about that just recently [12:22] apw: have you seen any not on shipova? [12:41] seb128, is ubuntu-desktop writable for me? [12:41] doko, yes [12:42] it has subteams set to allow anyone who can upload to be able to commit as well === dendrobates is now known as dendro-afk [13:28] pitti: hi, do you have a few minutes to copy over the Natty langpack updates from -proposed to -updates: https://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA [13:29] kelemengabor: queueing; I'm sure I can get to it today, but probably only in two hours or so [13:30] okay, thanks! [13:30] kelemengabor: thanks to you for organizing the testing! [13:31] pitti, seb128, I have done a fix on Poppler, I bzr-branched bzr: ERROR: No push location known or specified. [13:31] till@till:~/ubuntu/poppler/bzr/ubuntu$ less .bzr/branch [13:31] branch/ branch-format branch-lock/ [13:31] till@till:~/ubuntu/poppler/bzr/ubuntu$ less .bzr/branch/ [13:31] branch.conf format last-revision lock/ tags [13:31] till@till:~/ubuntu/poppler/bzr/ubuntu$ less .bzr/branch/branch.conf [13:31] till@till:~/ubuntu/poppler/bzr/ubuntu$ bzr push --remember http://bazaar.launchpad.net/~ubuntu-desktop/poppler/ubuntu/ and want to push my changes. To which URL do I have to push? [13:31] tkamppeter: You can't push to http URLs [13:32] tkamppeter, lp:~ubuntu-desktop/poppler/ubuntu [13:32] StevenK, I getbzr push --remember http://bazaar.launchpad.net/~ubuntu-desktop/poppler/ubuntu/ [13:32] bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~ubuntu-desktop/poppler/ubuntu/.bzr/branch/lock): Transport operation not possible: http does not support mkdir() [13:32] tkamppeter: Yes, because you can't push to http URLs [13:32] tkamppeter, use lp:~ubuntu-desktop/poppler/ubuntu [13:33] seb128, thanks, but I get then: [13:33] bzr: ERROR: Cannot lock LockDir(lp-89119376:///~ubuntu-desktop/poppler/ubuntu/.bzr/branchlock): Transport operation not possible: readonly transport [13:33] You need to login [13:33] Run bzr lp-login [13:33] seb128: oh, the package is missing a Vcs-Bzr: then [13:34] pitti, seems so indeed :-( [13:34] sorry about that [13:35] bzr lp-login returns my user name and then doing bzr push lp:~ubuntu-desktop/poppler/ubuntu again gives [13:35] bzr: ERROR: Cannot lock LockDir(lp-89229968:///~ubuntu-desktop/poppler/ubuntu/.bzr/branchlock): Transport operation not possible: readonly transport [13:35] I was about to say "debcheckout -a poppler", but that wouldn't work here then === dendro-afk is now known as dendrobates [13:37] Argh! Where did View->Source go in Firefox 6? [13:38] StevenK: Tools -> Web Developer -> Page Source. also, ctrl + U [13:39] nigelb: Indeed, I just found that myself. Thanks! [13:39] What a silly change. [13:39] I just use firebug usually [13:43] seb128, any further tips to bet the bzr push working? [13:43] tkamppeter, you maybe don't have access to that vcs [13:43] tkamppeter, do a merge request? [13:46] seb128, is it perhaps core-dev-only? [13:47]