[00:02] hm. very cool ftbfs page - it's grown colour! [00:06] Hobbsee: url? [00:06] sabdfl: http://qa.ubuntuwire.com/ftbfs/ [00:07] that is nice [00:07] * ScottK waves at sabdfl and says thanks for the +1 on clamav micro-version updates. [00:07] * directhex waves at sabdfl generally [00:08] Hobbsee: it is pretty nice looking [00:08] np ScottK [00:08] long list [00:09] lots of armel :-) [00:09] indeed. [00:09] * Hobbsee is looking at the failed to upload ones [00:12] hppa isn't so happy either. [00:12] no, I noticed that [00:13] hasn't hppa been around for a while? [00:13] yeah, but nobody tests on it because they have no simple means to do so [00:13] they just wait for build fail messages from assorted archives, and often ignore them as unreporducible [00:15] LaserJock: Also there's a soyuz bug that causes kde4bindings to get skipped on hppa currently, so the entire rest of the KDE stack is FTBFS. [00:15] That's several handfuls of them. [00:15] NCommander: are you planning to merge across firebird2.0 again, to make it installable this time? [00:16] ScottK: oh? what soyuz bug? [00:16] Hobbsee: Bug 311952 [00:16] Launchpad bug 311952 in soyuz "Packages-arch-specific blocking of a single binary blocks the entire source package" [Medium,Triaged] https://launchpad.net/bugs/311952 [00:16] tasty. [00:17] ScottK: interesting [00:17] I don't get Medium, but that's just me. I guess building packages isn't an important function for Soyuz. [00:17] ;-) [00:18] ScottK: well, they can't mark *everything* critical. [00:18] & high [00:18] no? [00:19] well, they could, but it wouldn't be so useful. [00:20] that implies it's useful now ... :-) [00:28] NCommander: ignore that. merged it myself. [00:40] NCommander: OTOH, it would be nice if you actually went back and fixed build failures for packages that failed across the board, after your changes. [00:42] Hobbsee, actually, I was going to request firebird 2.0 be removed, it didn't fail to build, it just failed to upload [00:43] that counts, i'm sure :P [00:43] so it can be removed? [00:43] it seems debian's designing it to be coinstallable [00:43] * TheMuso should look at powerpc FTBFs later. [00:44] brb, need to run to the store [00:44] * NCommander needs a torx screwdriver [00:45] NCommander: or at least, it counts when it's due to a packaging bug, not a soyuz bug. [00:46] james_w: shame there's no interface to binary publishing records in the LP API yet [00:46] (ppamadison) [00:47] cjwatson: indeed. [00:47] james_w: I knocked up a similar lpmadison prototype for Ubuntu the other day, but shelved it for the time being as it's not all that useful with just sources [00:48] but source publishing is a fairly recent addition so I imagine it's on the cards ... [00:49] * directhex hands NCommander his xbox moddin' screwdriver set [01:06] hi, i just noticed, that in jaunty using the intel driver there is an entry missing in /proc/mtrr, but i'm not sure if this a bug or an intentional behaviour (with that new memory management stuff going on etc) [01:07] adding the entry back gets the ttys working again (those were broken before) and lets glxgears run two times as fast [01:09] what confuses me a bit is that when i restart xorg by quitting gnome the entry gets removed again, so would that be a xorg driver issue? [01:10] reg04: base=0x0b0000000 ( 2816MB), size= 256MB, count=1: write-combining [01:10] thats the entry btw. [01:38] doko__: how much work would it be to incorporate the OpenSolaris .sh files (from jdk-distros) into the sun-java6 source package? [02:20] hello [02:20] This bug still exists in Ubuntu 8.10 for X86_64: https://bugs.launchpad.net/ubuntu/+source/hal/+bug/211569 [02:20] Launchpad bug 211569 in hal "xsane won't start unless run as root (Epson Perfection 1240)" [Medium,Fix released] [02:22] calc, I summon thy! [02:23] calc: whoah, where did you go all these year?? [02:23] years [02:25] NCommander: Er, thee [02:25] * NCommander pulls the source package [02:31] NCommander: Even if you have the source package, it's still thee. [02:39] NCommander: eh? [02:39] Roey: huh? [02:39] calc: hey [02:39] remember me? [02:39] Chris [02:39] Roey: yea iirc from debian-kde? [02:39] er [02:39] yes yes [02:40] Chris what's up??? I didn't know you do Ubuntu now [02:40] Roey: yea i switched to using ubuntu around sept 2004 [02:40] ahh interesting [02:40] Roey: then started working on ubuntu june 2007 on OOo [02:40] and you don't use KDE then? [02:40] ok [02:40] not anymore, no [02:41] i'll have to see how kde 4 shapes up over the next few releases :) [02:42] ahhhhh [02:42] I was almost ready to give up on this [02:42] I went to the release party in California last January [02:42] met a whole bunch of devs [02:42] calc, cool, that worked. [02:42] the "known" names etc. [02:42] calc, any idea when OOo in main will be fixed? [02:43] oh, since you're here, Chris, couldja help me with this [02:43] This bug still exists in Ubuntu 8.10 for X86_64: https://bugs.launchpad.net/ubuntu/+source/hal/+bug/211569 [02:43] Launchpad bug 211569 in hal "xsane won't start unless run as root (Epson Perfection 1240)" [Medium,Fix released] [02:44] NCommander: in jaunty? [02:44] NCommander: once the last two build-depends are fixed, two FTBFS from them for conversion to default-java [02:44] actually xom iirc FTBFS in general even without conversion [02:44] davidm, fixed already [02:45] davidm, or at least they're built. [02:45] er [02:45] sorry, calc [02:45] calc: But you want stlport4.6 on i386, which is in universe, and has been since dapper [02:45] Roey: cool, i was in california last month at UDS :) [02:45] :) [02:45] * Roey high-fives calc [02:45] StevenK: ugh ok, i'll have to beat on that for i386, didn't notice it since i use amd64 here [02:46] calc, I can look into fixing the issues [02:46] i'm making a 1:3.0.1~rc1-2ubuntu1 build right now [02:46] calc: do you work for Canonical now? [02:46] NCommander: there is a mir for the packages [02:46] calc: According to NCommander, we had a change to not use stlport4.6 since Hardy [02:46] NCommander: bug 305790 [02:46] StevenK: yea but in the sync to debian got dropped probably since 2.4.1 -> 3.0 was a lot of changes in the rules file [02:46] Launchpad bug 305790 in suitesparse "MIR - move to main for openoffice.org 3 build-depends" [Undecided,Fix released] https://launchpad.net/bugs/305790 [02:47] StevenK: rules file is somewhere north of 3500 lines :-( [02:47] * StevenK shivers [02:47] calc, I can look at fixing it [02:47] i'm sure i can fix up the stlport issue for i386 [02:47] calc, I'm fairly sure where I need to go to disable STLPORT usage [02:47] NCommander: the xom package randomly fails on amd64 at least [02:48] define randomly fails [02:48] NCommander: it built for me so i uploaded it, then it failed on buildd, tested on my machine failed, i changed the deps a bit it built, uploaded to buildd where it failed again, heh [02:48] Haha [02:48] building inside a chroot [02:48] So it builds fine on your machine, and going boom in a chroot? [02:48] NCommander: it built twice on my machine failed once and failed both times on the buildd [02:49] i haven't worked on it in a while though [02:49] calc: It's because crested and yellow hate you [02:49] can you define the failure for me? [02:49] NCommander: er i don't recall where it failed its in the build log though [02:49] * NCommander grabs the source package [02:49] NCommander: last time i looked at it was before my christmas vacation [02:50] xom is universe .... [02:50] O_o; [02:50] NCommander: yea i was converting to default-java to get it moved into main [02:50] Oh, so its going to main once you can fix this failure bug, right? [02:50] yes [02:50] any objections if I take a swing at it? [02:51] NCommander: no problem from me :) [02:51] NCommander: i had ~ 12 other packages to do at the time so didn't look at it too long but it looked really odd the way it was failing [02:52] calc, that's impressive [02:52] calc, your compiler getting stuck in an infinite loop [02:53] calc, is xom VCS packaged, or can I just fire into universe once I get it building? [02:54] NCommander: not sure if there is a vcs for it, i just grabbed it with apt-get [02:56] StevenK, send me an update before you drop off tonight, I have a status meeting with woei tomorrow. [02:56] If anyone is interested in getting experience with Ubuntu processes, apparently libtest-warn-perl needs a MIR so libnet-ssleay-perl will build. [02:59] I'm writing a script that I hope can become part of people.ubuntu.com/~ubuntu-archive/ reporting. Does that machine have filesystem level (read) access to the ubuntu archive, or should the script download files via http? [03:00] maxb: (a) yes it does (b) don't worry anyway, we'll adjust it as needed [03:01] maxb: (actually the stuff that shows up on people.ubuntu.com/~ubuntu-archive/ is mostly run on the master archive system and rsynced/scped over [03:01] ) [03:02] ok then, there's a script in lp:~maxb/+junk/ubuntu-archive-reporting for consideration. Should I send mail/bug somewhere? [03:02] erm, and I should probably document it better too [03:02] maxb: mail ubuntu-archive@lists.ubuntu.com please [03:03] cjwatson: I've removed you from the changelog in livecd-rootfs, since umpc is going away. (In bzr) [03:03] ok [03:03] * maxb will sleep now, go over it adding comments, and then send mail tomorrow [03:04] cjwatson: If I pastebin my diff, will you sanity check it? The changes are mostly harmless [03:04] StevenK: not now (bed), maybe later [03:05] * StevenK checks what time it is in London. [03:05] Eek [03:06] * maxb is being somewhat nocturnal :-) [03:06] Guys have a look at: https://arm.wiki.canonical.com/Home/Freescale and add drivers and what not that you think we need please. [03:06] maxb: why not use python-apt for version comparison? [03:07] NM wrong channel [03:07] apt_pkg.VersionCompare I believe [03:07] maxb: you could use it for stanza parsing too [03:07] anyway, bed [03:08] aha. the apt apidoc is a bit... nonexistent [03:09] I don't think using it for stanza parsing is an option, if I'm reading the .bz2 files (which is all I have locally) [03:09] I'll investigate a bit more, anyway [03:21] O_O; [03:21] Things you DON"T want to see during apt-get dist-upgrade: [03:21] Removing xserver-xorg ... [03:22] * ion_ recommends aptitude [03:38] StevenK: ok i got stlport removed from build-dep for new packages i am working on === ember_ is now known as ember [04:36] is there a way to clear the apt cache in synaptic, a user needs help doing it, but i don't use synaptic [04:36] there download seems corrupt [04:36] er their [04:41] i just told them the apt-get way [05:47] hey i need the source of ubuntu desktop [05:47] plz help me [05:51] karthik_: What package from the Ubuntu desktop do you want source for? [05:52] TheMuso: libwnck and the packages which we use for switching workspaces [05:53] karthik_: Ok I don't know what packages are used for switching workspaces, but you can fetch the libwnck source package by running "apt-get source libwnck" which will download the source package for you, providing you have a deb-src line in /etc/apt/sources.list. [05:53] Note that I am not sure that is the exact source package name, you will have to check. [05:54] ok === racarr_ is now known as racarr [06:52] Good morning [06:55] morning pitti === tkamppeter_ is now known as tkamppeter [07:00] good morning [07:01] * pitti dist-upgrades and hopes that the new udev won't break the world [07:01] pitti: it's all going to be good :) [07:01] pitti: the changelog looked "this has potential to break everything" too :) [07:04] argh, "No space left on device" -- see, udev broke everything!!!11!! [07:05] mvo: wishlist: make sudo apt-get autoclean work while apt-get dist-upgrade is in progress [07:25] StevenK: if you process NEW today, can you please look at calibre? I uploaded it, so I can't NEW it myself [07:25] pitti: Certainly [08:46] pitti: about bug 314772, mountnfs.orig is not listed in conffiles, so does dpkg still handle it as one? [08:46] Launchpad bug 314772 in sysvinit "superfluous /etc/network/if-up.d/mountnfs.orig in initscripts" [Medium,Confirmed] https://launchpad.net/bugs/314772 [09:04] tjaalton: oh; hm, one needs to check /var/lib/dpkg/status for that [09:04] tjaalton: do you have an affected system/ [09:04] ? [09:05] pitti: yes, dpkg --status initscripts doesn't list the file as a conffile [09:05] tjaalton: so you have the file, and if you upgrade, it goes away? [09:06] pitti: heh, I should probably try :) [09:07] pitti: yep, vanished [09:07] tjaalton: ok, thanks; bug updated, please upload [09:10] pitti: thanks, done [09:19] pitti: heh, so the version was wrong (older than in the archive). I'll just use ubuntu45.1 then [09:19] pitti: Ah too bad, I started reviewing libproxy as well [09:19] pitti: I found a couple of packaging issues though http://paste.ubuntu.com/102088/ [09:19] All easy to fix [09:19] lool: I didn't give it a big review, just a shallow lintian-like check, to unblock GNOME in jaunty [09:20] Sure [09:20] lool: oh, good points; please copy them into the MIR [09:20] I'm doing that [09:23] lool: the am maintainer thing doesn't work nowadays, does it? [09:24] seb128: I don't understand [09:24] lool: what do you mean by "wrong order"? what revision did you review? I ran autoreconf to update the patch in the current revision [09:24] lool: <@lool> No AM_MAINTAINER_MODE [09:24] seb128: The patch starts by configure then patches configure.ac [09:24] So there's a chance that configure.ac gets a newer timestamp [09:24] hum right [09:24] And appears newer and triggers a rebuild of configure [09:25] You can't patch-in AM_MAINTAINER_MODE, so the autoreconf should be a separate patch [09:25] Also the patch(es) should be numbered, but that's minor [09:25] In fact I was about to simply go fix the package instead of listing the issues [09:25] what do you mean by " can't patch-in AM_MAINTAINER_MODE"? [09:25] I'm interested because I've similar issues on gvfs [09:26] If you add AM_MAINTAINER_MODE in a patch, you will have an issue in distclean where the configure.ac will have been updated and cdbs runs distclean with the patches unapplied [09:26] You can add AM_MAINTAINER_MODE in a patch if you are careful to distclean with the patches applied [09:26] it seems AM_MAINTAINER_MODE doesn't do anything nowadays [09:27] or I got something wrong [09:27] It should work [09:27] gvfs has a 01_maintainer_mode.patch and a autoreconf change [09:27] but the configure claims not knowing about the option [09:27] and I think somebody told me the maintainer mode is deprecated in the new autotools version [09:27] Ok; let me finish dealing with libproxy and I'll have a look and see if I see anything obvious [09:28] ok thanks [09:28] I wasn't aware of its deprecation [09:28] I'm not sure if that's true but I think somebody told me that [09:29] automake 1.10 had some fixes for AM_MAINTAINER_MODE; I would expect it's still supposed to work [09:34] lool: http://people.ubuntu.com/~seb128/gvfs_1.1.3-0ubuntu1.dsc http://people.ubuntu.com/~seb128/gvfs_1.1.3-0ubuntu1.diff.gz http://people.ubuntu.com/~seb128/gvfs_1.1.3.orig.tar.gz [09:35] lool: if you want to look at the new gvfs, you probably want to disable the webdav option to try to build it, it requires new libsoup using libproxy which is not available yet [09:39] "libtool: Version mismatch error. This is libtool 2.2.6, but the [09:39] libtool: definition of this LT_INIT comes from libtool 2.2.4. [09:39] libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6 [09:39] " [09:39] * seb128 kicks libtool [09:39] I ran autoreconf what else do you want! [09:41] your soul [09:43] not going to happen no ;-) [09:44] * seb128 kicks libtool harder [09:52] doko_: there? you changed gstreamer to "Don't run the testsuite on hppa (hangs the hppa ubuntu buildd, libraries are required as build dependencies)." [09:52] doko_: what do you mean "libraries are required as build dependencies" [09:53] that's the only ubuntu change we have [09:53] did you open a debian bug about that? [10:01] what is the magic to drop all disk caches (for simple benchmark purposes)? to see how fast a operation would take on a freshly booted system [10:03] echo 3 /proc/sys/vm/drop_caches [10:03] echo 3 > /proc/sys/vm/drop_caches # even [10:04] ISTR Behdad blogged about a way to hide the cache from processes hmm [10:04] I don't recall the specifics [10:04] thanks elmo [10:08] can't find it [10:08] Must have dreamed it! [10:47] so who owns debootstrap ... [10:47] apw: closest maintianer is probably cjwatson [10:47] poor colin [10:47] and how about apt [10:47] him too? [10:48] No, mvo rather [10:48] ahh ta [10:53] asac: Hey [10:54] asac: You already discussed this with seb128, but I need to understand the decision to push to Debian [10:54] asac: Hmm let me read the ubuntu-desktop backlog first [10:56] hi [10:57] we need your opinion [10:57] asac: I read yesterday's discussion; I didn't find a reason for disabling mozjs, but I might have missed it [10:57] how english users like to reed remaining time in apt / synaptic? [10:58] lool: reason is that mozjs isnt a real lib because upstream doesnt have a ABI/API policy [10:58] asac: I think it's required for .pac support; when I started using GNOME, it was a big feature missing from the picture: .pac support needed js support and that was overkill for gnome-vfs [10:58] now this is like: 1h5min32s [10:58] and hence we cannot use it in main [10:58] lool: upstream is working on improving that for js. i think debian tracks the ABI/API on their own. we dont do that [10:59] Ok, so there's a real Debian/Ubuntu difference here; hmm I guess I could lsb-release check and add a configure flag [10:59] so it might be ok to have in debian (though it definitly puts a risk on sec updates) [10:59] 1h 5min 32s is better? Or 1 h 5 min 32 s is better? Or Is the actually good? [11:00] lool: do you have a debian chroot or something at hand? [11:00] asac: Ah then it's probably a good motivation to disable that support in Debian for now [11:00] asac: I could reboot into Debian [11:00] lool: just check whether libmozjs is packaged in a separate package and shipped with version in /usr/lib [11:00] lool: well. the risk is not on your package, but on the xulrunner package [11:00] lool: i think its safe for you to keep it [11:01] You mean we might discover that it broke ABI without changing SONAME or something? [11:01] lool: if upstream breaks abi/api in a sec update it means that we need to push a new package into stable-security [11:01] Sure [11:01] thekorn: hello! can I ask p-lp-bugs to use staging? [11:01] lool: the burden is on xulrunner package ... so :) [11:02] lool: do you know what feature gets disabled? [11:02] ISTR galeon was in a similar situation [11:02] pitti, hi, yes you can, [11:03] >>> from launchpadbugs.lpconstants import HTTPCONNECTION [11:03] >>> Bug.set_connection_mode(HTTPCONNECTION.MODE.STABLE) [11:03] s/STABLE/STAGING [11:03] ah, cool [11:03] asac: the mozjs plugin which is used for .pac [11:04] You might be able to use .pac without js, not sure, but I expect it's used with js most of the time anyway [11:04] lool: pac ... is that automatic proxy thing? [11:04] .pac is basically a 3 lines js script saying something like "if ip address is in this range use proxy foo, otherwise direct" [11:04] asac: Yes [11:04] It might be possible to test URLs in the .pac too (if domain is local then direct) [11:05] thekorn: Does s/STABLE/EDGE/ work too? [11:05] StevenK, yes [11:05] lool: ok. my point is: disable it everywhere to force upstream to either complain more at mozilla about fixing their abi/api issue [11:06] or to notice that they should use something elsee [11:06] i am correct in thinking that packages in main may not depend on packages in other realms like universe [11:06] lool: i know that spidermonkey folks want to fix that abi/api issue. they just werent aware of that. what they need now is more people complaining so they assign proper priortiy to it ;) [11:07] maxb: see germinate, it does this [11:07] maxb: (stanza parsing using python-apt from bz2 input) [11:08] asac: Ok; I guess I see your point; my view on the topic is that I have no idea what this lib is going to gain us, the only thing I know I ever cared about is .pac and it wont work if we don't enable js, but then I don't use PAC personally [11:08] apw: that is correct [11:08] apw: although we often deal with that by promoting packages from universe to main; it depends on the situation [11:08] apw: what's up? (debootstrap) [11:09] lool: yeah. thats why i think that libproxy folks have to know about the issues. maybe they will reconsider their decision to use mozjs then [11:09] hmmm, yeah debootstapping jaunty is failing, it looks like udev depends on libvolume-id1 which seems to be universe [11:10] asac: Do you know of any alternative? [11:10] approximatly [11:10] hm, really? ok will investigate [11:10] I was sure I NEWed that into main [11:10] oh, I bet -2 arrived in the Window Of Confusion [11:10] libvolume-id1 | 136-2 | jaunty/universe | amd64, i386 [11:11] lool: not sure what they need exactly [11:11] asac: Simple JS evaluations [11:11] that sounds like a bad place, is that the gap between waking and the first coffee? [11:11] lool: do you have the source again? [11:11] asac: Grab libproxy from the archive and see src/plugins/mozjs.c (the package is small and the plugin is small) [11:11] apw: fixed for the next publisher run; ETA about 1pm for visibility in the archive [11:12] thekorn: hm, I get a launchpadbugs.exceptions.LaunchpadURLError: ("message: unknown error"), but it does try to talk to staging [11:12] apw: do you care enough about a quick explanation? :) [11:12] heh ... i always like amusing stories [11:12] JS_DefineFunction(self->ctx, global, "dnsResolve", dnsResolve, 1, 0); (to call into C from JS) and others then they run pacutils.js [11:12] pitti, is your cookie valid for staging? [11:12] thekorn: I just freshly exported it [11:12] so it should be [11:13] They call FindProxyForURL() in the .pac which I understand can use the pacutils.js lib [11:13] thekorn: .staging.launchpad.net TRUE / TRUE 1234556 staging Bla.Bla [11:13] apw: the component (main, universe, etc.) that a package lands in is determined by "overrides" set by archive admins; when a new package, i.e. one whose name currently doesn't exist in the archive, arrives then archive admins have to override it to the correct component [11:13] apw: now, I did get this right when I first processed it [11:14] lool: do you happen to know if debian has the totem bbc plugin too? (I assume not but want confirmation :) [11:14] pitti, it worked this morning, can you show me some code you are workng on [11:14] apw: unfortunately, there was a second upload in between my initial override and the point when that first upload was fully processed into the archive [11:14] thekorn: I instantiate a BugList object, too; I'm not using it AFAIK, but maybe I need to do that there, too? [11:14] mvo: I don't think so [11:14] apw: I waved that through without particularly checking it [11:14] mvo: checking [11:14] ahh yes, like you have to NEW all our kernel packages every time cause of the name changes [11:14] mvo: oh we do [11:14] so basically someone uploaded -1 and -2 in that two hour window [11:14] apw: but there's a window where the override is not really quite entirely applied, due to a Soyuz bug; if a new version arrives in that window, it'll show up with the older default overrides, i.e. universe [11:15] thekorn: http://people.ubuntu.com/~pitti/tmp/launchpad.py -> current code [11:15] mvo: Added 2008-12-06 by sjoerd [11:15] and so you see it the second time instead of it going magically tot he right place [11:15] in experimental [11:15] thekorn: ded 2008-12-06 by sjoerd [11:15] sorry [11:15] pitti, you have to do it for both objects, it's not global [11:15] thekorn: http://pastebin.com/f137de67c -> my current diff [11:15] cjwatson, your world is a painful spikey place to live [11:15] lool: i will think about it - guess a few days [11:15] lool: thanks, I check it out [11:16] asac: Thanks [11:16] lool: pac> this is a feature request for apt as well, what is the plan there? libproxy? [11:16] thekorn: still the same if I do that on BugList, too [11:16] mvo: We're discussing the fact that we disabled mozjs which is required for .pac in libproxy [11:16] cjwatson, the effect of the error was most unexpected. apt-get fails to install things it can install just because it also cannot install some older package which i don't even care about [11:17] lool: aha, ok [11:17] apw: yeah, apt likes its world to be consistent and gets rather upset when it isn't [11:17] apw: debootstrap probably left you with a system of installed packages whose dependencies weren't resolved [11:17] at which point all bets are off as far as apt's concerned [11:17] yes ... it did [11:17] whats mad is that unrelated dependancy trees are no longer installable [11:18] but i guess thats apt-get stupidness [11:18] cool ... worked round it [11:18] thekorn: if you have a ~/.lpcookies.txt, the script should just run for you, too (if you have python-apport installed) [11:18] apw: enable universe in sources.list, apt-get update, apt-get -f install [11:18] should resolve it [11:18] asac: There's a webkit plugin which does JS too it seems [11:19] mvo: So actually webkit is still built and should work [11:19] apw: or just apt-get install -f (that will remove the packages that it can not make happy) [11:19] But webkit is another issue in ubunut [11:19] seb128: ^ [11:19] thekorn: (launchpad.py updated) [11:19] james_w: regarding the bash-completion thing: shall we wait for the new version to be released and sync then? or shall I upload the merge? [11:19] So we probably don't lack full .pac support in Ubuntu right now, if we install libwebkit [11:20] mvo: removing udev probably not so good though [11:20] thekorn: I disabled the writing functions again and just downlaod a bug report; works on production, excepts on staging [11:20] lool: right [11:20] cjwatson: *cough* I missed that udev was the bad one [11:20] dholbach: I'm not sure, I don't know when they plan to release the new version. [11:20] pitti, ok, pulling latest apport now, [11:20] thekorn: the one in intrepid should suffice [11:20] james_w: right-o - I'll upload the merge then [11:20] cjwatson: it will probably make you type "Yes I know what I am doing and I want to do it and I don't care that you (apt) thinks its not a good idea, really!" [11:20] dholbach: I think two years worth of improvements is probably worth having noew [11:20] thekorn: I just changed launchpad.py (above URL) [11:21] (before it lets you removing that) [11:21] * mvo thinks that bzr-handle-patch is *love* [11:21] lool: http://code.google.com/p/google-gadgets-for-linux/source/browse/trunk/extensions/smjs_script_runtime/gen_libmozjs_glue.sh ;) [11:22] mvo: udev isn't *actually* essential :) [11:22] maybe i can reduce that to symbols that are known to be stable [11:22] mvo, in this case it wasn't willing to, but i thing it would have had to remove ubuntu-essential or similar [11:23] james_w: the first hunk of the patch - where does it come from? is it from the qdbus thing too? [11:23] ubuntu-minimal is not Essential: yes either [11:23] cjwatson: aha, right - its kind of essential but not Essential: yes :) [11:23] james_w: nevermind [11:23] yeah, it's not to the level where you would need special tools to put it back if you removed it [11:24] pitti, which version of py-lp-bugs are you using, the one in trepid or from trunk [11:24] which is the point of essential [11:24] thekorn: current jaunty (Version: 0.3.1) [11:24] thekorn: same as in intrepid; let me try trunk [11:25] pitti, worked for me, https://bugs.staging.launchpad.net/ubuntu/+source/gzip/+bug/89040 [11:25] Launchpad bug 89040 in gzip "[apport] gunzip crashed with SIGSEGV in read()" [Undecided,Invalid] [11:25] with the version in lp:python-launchpad-bugs [11:26] thekorn: thanks for trying; I get the same error with trunk, so it's probably a cookie problem then [11:26]