[00:02] <Hobbsee> hm.  very cool ftbfs page - it's grown colour!
[00:06] <sabdfl> Hobbsee: url?
[00:06] <Hobbsee> sabdfl: http://qa.ubuntuwire.com/ftbfs/
[00:07] <sabdfl> 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] <LaserJock> Hobbsee: it is pretty nice looking
[00:08] <sabdfl> np ScottK
[00:08] <sabdfl> long list
[00:09] <LaserJock> lots of armel :-)
[00:09] <Hobbsee> indeed.
[00:09]  * Hobbsee is looking at the failed to upload ones
[00:12] <ScottK> hppa isn't so happy either.
[00:12] <LaserJock> no, I noticed that
[00:13] <LaserJock> hasn't hppa been around for a while?
[00:13] <directhex> yeah, but nobody tests on it because they have no simple means to do so
[00:13] <directhex> they just wait for build fail messages from assorted archives, and often ignore them as unreporducible
[00:15] <ScottK> 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] <ScottK> That's several handfuls of them.
[00:15] <Hobbsee> NCommander: are you planning to merge across firebird2.0 again, to make it installable this time?
[00:16] <Hobbsee> ScottK: oh?  what soyuz bug?
[00:16] <ScottK> Hobbsee: Bug 311952
[00:16] <Hobbsee> tasty.
[00:17] <LaserJock> ScottK: interesting
[00:17] <ScottK> I don't get Medium, but that's just me.  I guess building packages isn't an important function for Soyuz.
[00:17] <ScottK> ;-)
[00:18] <Hobbsee> ScottK: well, they can't mark *everything* critical.
[00:18] <Hobbsee> & high
[00:18] <LaserJock> no?
[00:19] <Hobbsee> well, they could, but it wouldn't be so useful.
[00:20] <LaserJock> that implies it's useful now ... :-)
[00:28] <Hobbsee> NCommander: ignore that.  merged it myself.
[00:40] <Hobbsee> 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] <NCommander> 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] <Hobbsee> that counts, i'm sure :P
[00:43] <Hobbsee> so it can be removed?
[00:43] <Hobbsee> it seems debian's designing it to be coinstallable
[00:43]  * TheMuso should look at powerpc FTBFs later.
[00:44] <NCommander> brb, need to run to the store
[00:44]  * NCommander needs a torx screwdriver
[00:45] <Hobbsee> NCommander: or at least, it counts when it's due to a packaging bug, not a soyuz bug.
[00:46] <cjwatson> james_w: shame there's no interface to binary publishing records in the LP API yet
[00:46] <cjwatson> (ppamadison)
[00:47] <james_w> cjwatson: indeed.
[00:47] <cjwatson> 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] <cjwatson> 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] <borschty> 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] <borschty> adding the entry back gets the ttys working again (those were broken before) and lets glxgears run two times as fast
[01:09] <borschty> 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] <borschty> reg04: base=0x0b0000000 ( 2816MB), size=  256MB, count=1: write-combining
[01:10] <borschty> thats the entry btw.
[01:38] <rootard> doko__: how much work would it be to incorporate the OpenSolaris .sh files (from jdk-distros) into the sun-java6 source package?
[02:20] <Roey> hello
[02:20] <Roey> This bug still exists in Ubuntu 8.10 for X86_64:  https://bugs.launchpad.net/ubuntu/+source/hal/+bug/211569
[02:22] <NCommander> calc, I summon thy!
[02:23] <Roey> calc:  whoah, where did you go all these year??
[02:23] <Roey> years
[02:25] <StevenK> NCommander: Er, thee
[02:25]  * NCommander pulls the source package
[02:31] <ScottK-desktop> NCommander: Even if you have the source package, it's still thee.
[02:39] <calc> NCommander: eh?
[02:39] <calc> Roey: huh?
[02:39] <Roey> calc:  hey
[02:39] <Roey> remember me?
[02:39] <Roey> Chris
[02:39] <calc> Roey: yea iirc from debian-kde?
[02:39] <Roey> er
[02:39] <Roey> yes yes
[02:40] <Roey> Chris what's up??? I didn't know you do Ubuntu now
[02:40] <calc> Roey: yea i switched to using ubuntu around sept 2004
[02:40] <Roey> ahh interesting
[02:40] <calc> Roey: then started working on ubuntu june 2007 on OOo
[02:40] <Roey> and you don't use KDE then?
[02:40] <Roey> ok
[02:40] <calc> not anymore, no
[02:41] <calc> i'll have to see how kde 4 shapes up over the next few releases :)
[02:42] <Roey> ahhhhh
[02:42] <Roey> I was almost ready to give up on this
[02:42] <Roey> I went to the release party in California last January
[02:42] <Roey> met a whole bunch of devs
[02:42] <NCommander> calc, cool, that worked.
[02:42] <Roey> the "known" names etc.
[02:42] <NCommander> calc, any idea when OOo in main will be fixed?
[02:43] <Roey> oh, since you're here, Chris, couldja help me with this
[02:43] <Roey> This bug still exists in Ubuntu 8.10 for X86_64:  https://bugs.launchpad.net/ubuntu/+source/hal/+bug/211569
[02:44] <calc> NCommander: in jaunty?
[02:44] <calc> NCommander: once the last two build-depends are fixed, two FTBFS from them for conversion to default-java
[02:44] <calc> actually xom iirc FTBFS in general even without conversion
[02:44] <NCommander> davidm, fixed already
[02:45] <NCommander> davidm, or at least they're built.
[02:45] <NCommander> er
[02:45] <NCommander> sorry, calc
[02:45] <StevenK> calc: But you want stlport4.6 on i386, which is in universe, and has been since dapper
[02:45] <calc> Roey: cool, i was in california last month at UDS :)
[02:45] <Roey> :)
[02:45]  * Roey high-fives calc
[02:45] <calc> StevenK: ugh ok, i'll have to beat on that for i386, didn't notice it since i use amd64 here
[02:46] <NCommander> calc, I can look into fixing the issues
[02:46] <calc> i'm making a 1:3.0.1~rc1-2ubuntu1 build right now
[02:46] <Roey> calc:  do you work for Canonical now?
[02:46] <calc> NCommander: there is a mir for the packages
[02:46] <StevenK> calc: According to NCommander, we had a change to not use stlport4.6 since Hardy
[02:46] <calc> NCommander: bug 305790
[02:46] <calc> 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:47] <calc> StevenK: rules file is somewhere north of 3500 lines :-(
[02:47]  * StevenK shivers
[02:47] <NCommander> calc, I can look at fixing it
[02:47] <calc> i'm sure i can fix up the stlport issue for i386
[02:47] <NCommander> calc, I'm fairly sure where I need to go to disable STLPORT usage
[02:47] <calc> NCommander: the xom package randomly fails on amd64 at least
[02:48] <NCommander> define randomly fails
[02:48] <calc> 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] <StevenK> Haha
[02:48] <calc> building inside a chroot
[02:48] <NCommander> So it builds fine on your machine, and going boom in a chroot?
[02:48] <calc> NCommander: it built twice on my machine failed once and failed both times on the buildd
[02:49] <calc> i haven't worked on it in a while though
[02:49] <StevenK> calc: It's because crested and yellow hate you
[02:49] <NCommander> can you define the failure for me?
[02:49] <calc> NCommander: er i don't recall where it failed its in the build log though
[02:49]  * NCommander grabs the source package
[02:49] <calc> NCommander: last time i looked at it was before my christmas vacation
[02:50] <NCommander> xom is universe ....
[02:50] <NCommander> O_o;
[02:50] <calc> NCommander: yea i was converting to default-java to get it moved into main
[02:50] <NCommander> Oh, so its going to main once you can fix this failure bug, right?
[02:50] <calc> yes
[02:50] <NCommander> any objections if I take a swing at it?
[02:51] <calc> NCommander: no problem from me :)
[02:51] <calc> 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] <NCommander> calc, that's impressive
[02:52] <NCommander> calc, your compiler getting stuck in an infinite loop
[02:53] <NCommander> calc, is xom VCS packaged, or can I just fire into universe once I get it building?
[02:54] <calc> NCommander: not sure if there is a vcs for it, i just grabbed it with apt-get
[02:56] <davidm> StevenK, send me an update before you drop off tonight, I have a status meeting with woei tomorrow.
[02:56] <ScottK> 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] <maxb> 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] <cjwatson> maxb: (a) yes it does (b) don't worry anyway, we'll adjust it as needed
[03:01] <cjwatson> 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] <cjwatson> )
[03:02] <maxb> ok then, there's a script in lp:~maxb/+junk/ubuntu-archive-reporting for consideration. Should I send mail/bug somewhere?
[03:02] <maxb> erm, and I should probably document it better too
[03:02] <cjwatson> maxb: mail ubuntu-archive@lists.ubuntu.com please
[03:03] <StevenK> cjwatson: I've removed you from the changelog in livecd-rootfs, since umpc is going away. (In bzr)
[03:03] <cjwatson> ok
[03:03]  * maxb will sleep now, go over it adding comments, and then send mail tomorrow
[03:04] <StevenK> cjwatson: If I pastebin my diff, will you sanity check it? The changes are mostly harmless
[03:04] <cjwatson> StevenK: not now (bed), maybe later
[03:05]  * StevenK checks what time it is in London. 
[03:05] <StevenK> Eek
[03:06]  * maxb is being somewhat nocturnal :-)
[03:06] <davidm> 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] <cjwatson> maxb: why not use python-apt for version comparison?
[03:07] <davidm> NM wrong channel
[03:07] <cjwatson> apt_pkg.VersionCompare I believe
[03:07] <cjwatson> maxb: you could use it for stanza parsing too
[03:07] <cjwatson> anyway, bed
[03:08] <maxb> aha. the apt apidoc is a bit... nonexistent
[03:09] <maxb> 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] <maxb> I'll investigate a bit more, anyway
[03:21] <NCommander> O_O;
[03:21] <NCommander> Things you DON"T want to see during apt-get dist-upgrade:
[03:21] <NCommander> Removing xserver-xorg ...
[03:22]  * ion_ recommends aptitude
[03:38] <calc> StevenK: ok i got stlport removed from build-dep for new packages i am working on
[04:36] <calc> 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] <calc> there download seems corrupt
[04:36] <calc> er their
[04:41] <calc> i just told them the apt-get way
[05:47] <karthik_> hey i need the source of ubuntu desktop
[05:47] <karthik_> plz help me
[05:51] <TheMuso> karthik_: What package from the Ubuntu desktop do you want source for?
[05:52] <karthik_> TheMuso: libwnck and the packages which we use for switching workspaces
[05:53] <TheMuso> 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] <TheMuso> Note that I am not sure that is the exact source package name, you will have to check.
[05:54] <karthik_> ok
[06:52] <pitti> Good morning
[06:55] <LaserJock> morning pitti
[07:00] <dholbach> good morning
[07:01]  * pitti dist-upgrades and hopes that the new udev won't break the world
[07:01] <dholbach> pitti: it's all going to be good :)
[07:01] <dholbach> pitti: the changelog looked "this has potential to break everything" too :)
[07:04] <pitti> argh, "No space left on device" -- see, udev broke everything!!!11!!
[07:05] <pitti> mvo: wishlist: make sudo apt-get autoclean work while apt-get dist-upgrade is in progress
[07:25] <pitti> StevenK: if you process NEW today, can you please look at calibre? I uploaded it, so I can't NEW it myself
[07:25] <StevenK> pitti: Certainly
[08:46] <tjaalton> pitti: about bug 314772, mountnfs.orig is not listed in conffiles, so does dpkg still handle it as one?
[09:04] <pitti> tjaalton: oh; hm, one needs to check /var/lib/dpkg/status for that
[09:04] <pitti> tjaalton: do you have an affected system/
[09:04] <pitti> ?
[09:05] <tjaalton> pitti: yes, dpkg --status initscripts doesn't list the file as a conffile
[09:05] <pitti> tjaalton: so you have the file, and if you upgrade, it goes away?
[09:06] <tjaalton> pitti: heh, I should probably try :)
[09:07] <tjaalton> pitti: yep, vanished
[09:07] <pitti> tjaalton: ok, thanks; bug updated, please upload
[09:10] <tjaalton> pitti: thanks, done
[09:19] <tjaalton> pitti: heh, so the version was wrong (older than in the archive). I'll just use ubuntu45.1 then
[09:19] <lool> pitti: Ah too bad, I started reviewing libproxy as well
[09:19] <lool> pitti: I found a couple of packaging issues though http://paste.ubuntu.com/102088/
[09:19] <lool> All easy to fix
[09:19] <pitti> lool: I didn't give it a big review, just a shallow lintian-like check, to unblock GNOME in jaunty
[09:20] <lool> Sure
[09:20] <pitti> lool: oh, good points; please copy them into the MIR
[09:20] <lool> I'm doing that
[09:23] <seb128> lool: the am maintainer thing doesn't work nowadays, does it?
[09:24] <lool> seb128: I don't understand
[09:24] <seb128> 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] <seb128> lool: <@lool> No AM_MAINTAINER_MODE
[09:24] <lool> seb128: The patch starts by configure then patches configure.ac
[09:24] <lool> So there's a chance that configure.ac gets a newer timestamp
[09:24] <seb128> hum right
[09:24] <lool> And appears newer and triggers a rebuild of configure
[09:25] <lool> You can't patch-in AM_MAINTAINER_MODE, so the autoreconf should be a separate patch
[09:25] <lool> Also the patch(es) should be numbered, but that's minor
[09:25] <lool> In fact I was about to simply go fix the package instead of listing the issues
[09:25] <seb128> what do you mean by " can't patch-in AM_MAINTAINER_MODE"?
[09:25] <seb128> I'm interested because I've similar issues on gvfs
[09:26] <lool> 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] <lool> You can add AM_MAINTAINER_MODE in a patch if you are careful to distclean with the patches applied
[09:26] <seb128> it seems AM_MAINTAINER_MODE doesn't do anything nowadays
[09:27] <seb128> or I got something wrong
[09:27] <lool> It should work
[09:27] <seb128> gvfs has a 01_maintainer_mode.patch and a autoreconf change
[09:27] <seb128> but the configure claims not knowing about the option
[09:27] <seb128> and I think somebody told me the maintainer mode is deprecated in the new autotools version
[09:27] <lool> Ok; let me finish dealing with libproxy and I'll have a look and see if I see anything obvious
[09:28] <seb128> ok thanks
[09:28] <lool> I wasn't aware of its deprecation
[09:28] <seb128> I'm not sure if that's true but I think somebody told me that
[09:29] <lool> automake 1.10 had some fixes for AM_MAINTAINER_MODE; I would expect it's still supposed to work
[09:34] <seb128> 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] <seb128> 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] <seb128> "libtool: Version mismatch error.  This is libtool 2.2.6, but the
[09:39] <seb128> libtool: definition of this LT_INIT comes from libtool 2.2.4.
[09:39] <seb128> libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6
[09:39] <seb128> "
[09:39]  * seb128 kicks libtool
[09:39] <seb128> I ran autoreconf what else do you want!
[09:41] <Mithrandir> your soul
[09:43] <seb128> not going to happen no ;-)
[09:44]  * seb128 kicks libtool harder
[09:52] <seb128> 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] <seb128> doko_: what do you mean "libraries are required as build dependencies"
[09:53] <seb128> that's the only ubuntu change we have
[09:53] <seb128> did you open a debian bug about that?
[10:01] <mvo> 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] <elmo> echo 3 /proc/sys/vm/drop_caches
[10:03] <elmo> echo 3 > /proc/sys/vm/drop_caches   # even
[10:04] <lool> ISTR Behdad blogged about a way to hide the cache from processes hmm
[10:04] <lool> I don't recall the specifics
[10:04] <mvo> thanks elmo
[10:08] <lool> can't find it
[10:08] <lool> Must have dreamed it!
[10:47] <apw> so who owns debootstrap ...
[10:47] <pitti> apw: closest maintianer is probably cjwatson
[10:47] <apw> poor colin
[10:47] <apw> and how about apt
[10:47] <apw> him too?
[10:48] <lool> No, mvo rather
[10:48] <apw> ahh ta
[10:53] <lool> asac: Hey
[10:54] <lool> asac: You already discussed this with seb128, but I need to understand the decision to push to Debian
[10:54] <lool> asac: Hmm let me read the ubuntu-desktop backlog first
[10:56] <sianis> hi
[10:57] <sianis> we need your opinion
[10:57] <lool> asac: I read yesterday's discussion; I didn't find a reason for disabling mozjs, but I might have missed it
[10:57] <sianis> how english users like to reed remaining time in apt / synaptic?
[10:58] <asac> lool: reason is that mozjs isnt a real lib because upstream doesnt have a ABI/API policy
[10:58] <lool> 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] <sianis> now this is like: 1h5min32s
[10:58] <asac> and hence we cannot use it in main
[10:58] <asac> 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] <lool> 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] <asac> so it might be ok to have in debian (though it definitly puts a risk on sec updates)
[10:59] <sianis> 1h 5min 32s is better? Or 1 h 5 min 32 s is better? Or Is the actually good?
[11:00] <asac> lool: do you have a debian chroot or something at hand?
[11:00] <lool> asac: Ah then it's probably a good motivation to disable that support in Debian for now
[11:00] <lool> asac: I could reboot into Debian
[11:00] <asac> lool: just check whether libmozjs is packaged in a separate package and shipped with version in /usr/lib
[11:00] <asac> lool: well. the risk is not on your package, but on the xulrunner package
[11:00] <asac> lool: i think its safe for you to keep it
[11:01] <lool> You mean we might discover that it broke ABI without changing SONAME or something?
[11:01] <asac> 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] <lool> Sure
[11:01] <pitti> thekorn: hello! can I ask p-lp-bugs to use staging?
[11:01] <asac> lool: the burden is on xulrunner package ... so :)
[11:02] <asac> lool: do you know what feature gets disabled?
[11:02] <lool> ISTR galeon was in a similar situation
[11:02] <thekorn> pitti, hi, yes you can,
[11:03] <thekorn> >>> from launchpadbugs.lpconstants import HTTPCONNECTION
[11:03] <thekorn> >>> Bug.set_connection_mode(HTTPCONNECTION.MODE.STABLE)
[11:03] <thekorn> s/STABLE/STAGING
[11:03] <pitti> ah, cool
[11:03] <lool> asac: the mozjs plugin which is used for .pac
[11:04] <lool> 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] <asac> lool: pac ... is that automatic proxy thing?
[11:04] <lool> .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] <lool> asac: Yes
[11:04] <lool> It might be possible to test URLs in the .pac too (if domain is local then direct)
[11:05] <StevenK> thekorn: Does s/STABLE/EDGE/ work too?
[11:05] <thekorn> StevenK, yes
[11:05] <asac> 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] <asac> or to notice that they should use something elsee
[11:06] <apw> i am correct in thinking that packages in main may not depend on packages in other realms like universe
[11:06] <asac> 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] <cjwatson> maxb: see germinate, it does this
[11:07] <cjwatson> maxb: (stanza parsing using python-apt from bz2 input)
[11:08] <lool> 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] <cjwatson> apw: that is correct
[11:08] <cjwatson> apw: although we often deal with that by promoting packages from universe to main; it depends on the situation
[11:08] <cjwatson> apw: what's up? (debootstrap)
[11:09] <asac> 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] <apw> hmmm, yeah debootstapping jaunty is failing, it looks like udev depends on libvolume-id1 which seems to be universe
[11:10] <lool> asac: Do you know of any alternative?
[11:10] <apw> approximatly
[11:10] <cjwatson> hm, really? ok will investigate
[11:10] <cjwatson> I was sure I NEWed that into main
[11:10] <cjwatson> oh, I bet -2 arrived in the Window Of Confusion
[11:10] <apw> libvolume-id1 |      136-2 | jaunty/universe | amd64, i386
[11:11] <asac> lool: not sure what they need exactly
[11:11] <lool> asac: Simple JS evaluations
[11:11] <apw> that sounds like a bad place, is that the gap between waking and the first coffee?
[11:11] <asac> lool: do you have the source again?
[11:11] <lool> asac: Grab libproxy from the archive and see src/plugins/mozjs.c (the package is small and the plugin is small)
[11:11] <cjwatson> apw: fixed for the next publisher run; ETA about 1pm for visibility in the archive
[11:12] <pitti> thekorn: hm, I get a launchpadbugs.exceptions.LaunchpadURLError: ("message: unknown error"), but it does try to talk to staging
[11:12] <cjwatson> apw: do you care enough about a quick explanation? :)
[11:12] <apw> heh ... i always like amusing stories
[11:12] <lool> JS_DefineFunction(self->ctx, global, "dnsResolve", dnsResolve, 1, 0); (to call into C from JS) and others then they run pacutils.js
[11:12] <thekorn> pitti, is your cookie valid for staging?
[11:12] <pitti> thekorn: I just freshly exported it
[11:12] <pitti> so it should be
[11:13] <lool> They call FindProxyForURL() in the .pac which I understand can use the pacutils.js lib
[11:13] <pitti> thekorn: .staging.launchpad.net TRUE / TRUE 1234556 staging Bla.Bla
[11:13] <cjwatson> 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] <cjwatson> apw: now, I did get this right when I first processed it
[11:14] <mvo> lool: do you happen to know if debian has the totem bbc plugin too? (I assume not but want confirmation :)
[11:14] <thekorn> pitti, it worked this morning, can you show me some code you are workng on
[11:14] <cjwatson> 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] <pitti> thekorn: I instantiate a BugList object, too; I'm not using it AFAIK, but maybe I need to do that there, too?
[11:14] <lool> mvo: I don't think so
[11:14] <cjwatson> apw: I waved that through without particularly checking it
[11:14] <lool> mvo: checking
[11:14] <apw> ahh yes, like you have to NEW all our kernel packages every time cause of the name changes
[11:14] <lool> mvo: oh we do
[11:14] <apw> so basically someone uploaded -1 and -2 in that two hour window
[11:14] <cjwatson> 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] <pitti> thekorn: http://people.ubuntu.com/~pitti/tmp/launchpad.py -> current code
[11:15] <lool> mvo: Added 2008-12-06 by sjoerd
[11:15] <apw> and so you see it the second time instead of it going magically tot he right place
[11:15] <lool> in experimental
[11:15] <pitti> thekorn: ded 2008-12-06 by sjoerd
[11:15] <pitti> sorry
[11:15] <thekorn> pitti, you have to do it for both objects, it's not global
[11:15] <pitti> thekorn: http://pastebin.com/f137de67c -> my current diff
[11:15] <apw> cjwatson, your world is a painful spikey place to live
[11:15] <asac> lool: i will think about it - guess a few days
[11:15] <mvo> lool: thanks, I check it out
[11:16] <lool> asac: Thanks
[11:16] <mvo> lool: pac> this is a feature request for apt as well, what is the plan there? libproxy?
[11:16] <pitti> thekorn: still the same if I do that on BugList, too
[11:16] <lool> mvo: We're discussing the fact that we disabled mozjs which is required for .pac in libproxy
[11:16] <apw> 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] <mvo> lool: aha, ok
[11:17] <cjwatson> apw: yeah, apt likes its world to be consistent and gets rather upset when it isn't
[11:17] <cjwatson> apw: debootstrap probably left you with a system of installed packages whose dependencies weren't resolved
[11:17] <cjwatson> at which point all bets are off as far as apt's concerned
[11:17] <apw> yes ... it did
[11:17] <apw> whats mad is that unrelated dependancy trees are no longer installable
[11:18] <apw> but i guess thats apt-get stupidness
[11:18] <apw> cool ... worked round it
[11:18] <pitti> thekorn: if you have a ~/.lpcookies.txt, the script should just run for you, too (if you have python-apport installed)
[11:18] <cjwatson> apw: enable universe in sources.list, apt-get update, apt-get -f install
[11:18] <cjwatson> should resolve it
[11:18] <lool> asac: There's a webkit plugin which does JS too it seems
[11:19] <lool> mvo: So actually webkit is still built and should work
[11:19] <mvo> apw: or just apt-get install -f (that will remove the packages that it can not make happy)
[11:19] <lool> But webkit is another issue in ubunut
[11:19] <lool> seb128: ^
[11:19] <pitti> thekorn: (launchpad.py updated)
[11:19] <dholbach> 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] <lool> So we probably don't lack full .pac support in Ubuntu right now, if we install libwebkit
[11:20] <cjwatson> mvo: removing udev probably not so good though
[11:20] <pitti> thekorn: I disabled the writing functions again and just downlaod a bug report; works on production, excepts on staging
[11:20] <seb128> lool: right
[11:20] <mvo> cjwatson: *cough* I missed that udev was the bad one
[11:20] <james_w> dholbach: I'm not sure, I don't know when they plan to release the new version.
[11:20] <thekorn> pitti, ok, pulling latest apport now,
[11:20] <pitti> thekorn: the one in intrepid should suffice
[11:20] <dholbach> james_w: right-o - I'll upload the merge then
[11:20] <mvo> 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] <james_w> dholbach: I think two years worth of improvements is probably worth having noew
[11:20] <pitti> thekorn: I just changed launchpad.py (above URL)
[11:21] <mvo> (before it lets you removing that)
[11:21]  * mvo thinks that bzr-handle-patch is *love*
[11:21] <asac> lool: http://code.google.com/p/google-gadgets-for-linux/source/browse/trunk/extensions/smjs_script_runtime/gen_libmozjs_glue.sh ;)
[11:22] <cjwatson> mvo: udev isn't *actually* essential :)
[11:22] <asac> maybe i can reduce that to symbols that are known to be stable
[11:22] <apw> mvo, in this case it wasn't willing to, but i thing it would have had to remove ubuntu-essential or similar
[11:23] <dholbach> james_w: the first hunk of the patch - where does it come from? is it from the qdbus thing too?
[11:23] <cjwatson> ubuntu-minimal is not Essential: yes either
[11:23] <mvo> cjwatson: aha, right - its kind of essential but not Essential: yes :)
[11:23] <dholbach> james_w: nevermind
[11:23] <cjwatson> yeah, it's not to the level where you would need special tools to put it back if you removed it
[11:24] <thekorn> pitti, which version of py-lp-bugs are you using, the one in trepid or from trunk
[11:24] <cjwatson> which is the point of essential
[11:24] <pitti> thekorn: current jaunty (Version: 0.3.1)
[11:24] <pitti> thekorn: same as in intrepid; let me try trunk
[11:25] <thekorn> pitti, worked for me, https://bugs.staging.launchpad.net/ubuntu/+source/gzip/+bug/89040
[11:25] <thekorn> with the version in lp:python-launchpad-bugs
[11:26] <pitti> thekorn: thanks for trying; I get the same error with trunk, so it's probably a cookie problem then
[11:26] <dholbach> james_w: uploaded, good work
[11:26] <thekorn> pitti, did you ever thought about moving to launchpadlib soonish? ;)
[11:27] <pitti> thekorn: heh, in fact I did, and I reported bugs againts launchpadlib for everything that's missing in order to move to it
[11:27] <lool> seb128: I don't have time to look at gvfs right now, and I'll probably wait until it's buildable
[11:27] <seb128> lool: ok, no hurry, thank you
[11:27] <pitti> thekorn: does p-lp-bugs store cookies or other cache information somewhere, which I could try and delete?
[11:28] <james_w> dholbach: rock. thanks.
[11:28] <thekorn> pitti, no, not by default, just if you run Bug.connection.save_cookie()
[11:28] <thekorn> but I think you don't
[11:29] <pitti> no, I don't
[11:29] <pitti> thekorn: I logged out and back in, and refreshed my cookie again, no help
[11:30] <pitti> thekorn: ok, nevermind; I'll just test on production then, *shrug* (it's not much)
[11:30] <thekorn> pitti, oh wait, there is ~/.python-launchpad-bugs.conf
[11:30] <thekorn>  with cookies, weird
[11:31] <pitti> aah
[11:31] <pitti> removed, but still the same crash
[11:31] <asac> lool: is the webkit js plugin  packaged individually or in the main lib?
[11:31] <pitti> thekorn: it was regenerated, this time without any cookies
[11:32] <thekorn> pitti, it should only be there when you run the testsuite, will try to find out why this file is there later today
[11:33] <pitti> thekorn: right, it does write cookies for lp and edge, but none for staging
[11:34] <pitti> thekorn: does your staging cookie look similar to mine?
[11:34] <pitti> i. e. it's ".launchpad.net ... edge" vs. ".staging.lauchpad.net ... staging" for me
[11:34] <thekorn> pitti, sorry, I'm using a FF3 sql cookie
[11:34] <pitti> thekorn: right, I generated it with cookies-sql2txt
[11:35] <asac> lool: k found it
[11:35] <pitti> thekorn: can p-lp-bugs use sqlite now?
[11:35] <thekorn> pitti, yes, just use the sql one
[11:36] <pitti> thekorn: ok, that didn't help
[11:39] <Baby> pitti: ping!
[11:39] <pitti> hey Baby
[11:39] <pitti> (it feels so weird saying that...)
[11:39] <thekorn> hehe
[11:39] <Baby> :)
[11:40] <Baby> pitti: I made some corrections to the copyright file, I plan to upload it to NEW this afternoon, will that be OK for you? :)
[11:40] <Baby> NEW -> Debian
[11:40] <pitti> \o/
[11:40] <pitti> Baby: sure
[11:41] <Baby> cool :) great then!
[11:41] <pitti> Baby: I need to fix the packaging to use dh_installudev, so that we can sync it to Ubuntu, too (and also because it's cleaner), but that's my only TODO item right now
[11:41] <pitti> Baby: I can do that after the initial upload, too
[11:41] <pitti> Baby: please just use dch -r/debcommit -r when you upload, and push
[11:43] <Baby> will you be online this afternoon?
[11:43] <pitti> Baby: yes, barring lunch break
[11:44] <Baby> cool, I'll try to do it when I have you online then :)
[13:15] <thekorn> pitti, I just has a quick look at apport's launchpad.py, I think the only two things missing in the API are removing attachments and an API for +storeblob
[13:15] <thekorn> did you already file bugreports for these?
[13:41] <nnull> why is the inputbox for remote desktop limited to a 8char string?.. seem's silly.. as anything that small is rather crackable?...
[13:42] <doko_> seb128: I don't expect any uses of gstreamer on hppa, but the libaries are needed as build dependencies for other packages. I don't see the tests failing in debian
[13:43] <seb128> doko_: any idea why the debian buildds would work fine and the ubuntu ones have issues there?
[13:43] <seb128> doko_: should we try to sync the current version to see if that's still an issue?
[13:46] <doko_> seb128: I don't think so, did succeed in Debian before the update as well. there's a kernel patch pending for other threading issues, not sure if/when this will be applied.
[13:46] <doko_> lamont: ^^^
[13:47] <lamont> seb128: what's the failure?
[13:47] <lamont> the biggest diff is NPTL crack, generally
[13:47] <seb128> lamont: dunno, doko did disable the gstreamer0.10 testsuite on hppa because it hangs the ubuntu buildds apparently
[13:47] <seb128> lamont: that's the only diff we have on debian and syncing that package would be nice
[13:48] <doko_> look at the build logs for the failed builds
[13:48] <seb128> lamont: the same package builds fine on debian hppa apparently
[13:48] <doko_> lamont: I mean the issue mentioned in http://bugs.debian.org/509555
[13:49] <ScottK> doko_: Do you have any plans for Python 3.0 support in python-central this cycle?
[13:49] <seb128> lamont: http://launchpadlibrarian.net/18941051/buildlog_ubuntu-intrepid-hppa.gstreamer0.10_0.10.21-4_FAILEDTOBUILD.txt.gz
[13:51] <doko_> ScottK: yes
[13:52] <fasta> After an upgrade to 8.10 pthreads is not being found by ld anymore, even though libc6-dev is installed. When I run ld in verbose mode, I see that it never tries to find it in /usr/lib/. I can only assume that you changed that. Did you and if so, why and what's the solution to the problem?
[13:52] <lamont> it's possible that kyle fixed some of the bugs and the ubuntu kernel is lacking said fixes
[13:52] <ScottK> doko_: Great.  One of my Python module packages just released a new upstream with Python3.0 support and I'm interested to get it packaged.
[13:52] <lamont> 2.6.26-bpo.1-parisc64-smp is what's on the debian buildd
[13:52] <lamont> and I _KNOW_ we don't have that on the ubuntu buildds
[13:53] <lamont> doko_: though, to be fair, I'm not far from just saying "let's make intrepid the final release of ubuntu/hppa"
[13:55] <lamont> doko_: but I need to go do the research and see how much archive traffic hppa has been getting (and subtract out buildds and developers-fixing-bugs-for-the-buildds from the list) to see what, if any actual use/demand there is for it
[13:56] <directhex> who are the real-world "market" for hppa ubuntu?
[14:03] <doko_> lamont: how far do you need to be pushed?
[14:14] <lamont> directhex: the hppa port was done "because we (for a very small definition of 'we') can, and without any business rationale" or words to that effect when we (fabbione and I) announced the sparc and hppa ports
[14:15] <mok0> It'
[14:15] <lamont> and the suspicion is that 99% of the hppa packages being fetched are: 1) buildds, 2) devs fixing bugs found by the buildds, and 3) mirrors
[14:16] <lamont> I'd give it more nines, but I'm not sure we're past 100 unique IPs, either...]
[14:16] <mok0> It's actually useful to see if code compiles well on hppa and sparc
[14:16] <ghostcube> hi folks me again and i wanted to ask again why only kubuntu isnt shipping jackd xine-lib support
[14:16] <lamont> mok0: yes
[14:16] <ghostcube> its the only kde4 based distrie not doing this
[14:16] <lamont> hppa is big-endian, and can be made bitchy about alignment issues, etc.
[14:17] <lamont> ghostcube: that sounds like a #kubuntu question
[14:17] <ScottK> ghostcube: #kubuntu-devel might be a better place for Kubuntu questions.
[14:17] <ghostcube> nope
[14:17] <ghostcube> its a xine-lib problem
[14:17] <directhex> don't sun ship sparc servers with ubuntu?
[14:17] <ghostcube> not kubuntu related
[14:17] <Riddell> ghostcube: because jack isn't in main
[14:17] <ghostcube> they send me here
[14:18] <ghostcube> Riddell, i heard this tghe last time too but it cant be that ubuntu is taken this out even if debian and suse ship it
[14:18]  * lamont defers to Riddell 
[14:18] <ghostcube> i dont want to change the distrie only for this
[14:18] <mok0> ghostcube: pls explain the problem
[14:19] <ghostcube> ok xine-lib normally has an build in jackd output support since 1.1.3  so you can set jackd as an audio output source inside the systemsettings of kde 4
[14:19] <ghostcube> but it seems that ubuntu has taken this out for a problem in gutsy
[14:19] <directhex> lamont, IMHO it's hard for contributors to get fired up about an arch they will never ever see. how do you test something on hppa or arm, without a full-on package upload to the archive? you end up with only porting specialists caring
[14:20] <mok0> ghostcube: do you know why?
[14:20] <mok0> ghostcube: Is there a bug report or something?
[14:20] <ghostcube> and i can show u a screenshot from debian and suse where it works i have been to #kde asking for this they told me that this works but only on ubuntu or kubuntu not
[14:20] <ghostcube> mok0, yes
[14:20] <ghostcube> moment if i can find it
[14:21] <Riddell> really, it's not a bug, we don't support jack that's all
[14:22] <mok0> Riddell: so it's been taken out on purpose?
[14:22] <ScottK> One of the defining features that differentiates *buntu from Debian is to pick one particular tool for a job and focus support on that and not try to support the world.
[14:22] <ScottK> Jack isn't the one we picked.
[14:23] <directhex> moar sound daemons!
[14:24] <Riddell> mok0: yes, jack isn't in main
[14:24] <pitti> thekorn: at least for storeblob, yes; I also filed something else
[14:25] <ghostcube> ScottK, jackd is needed for musicans ok so i know this i just change my distrie to make music with the jackd support on debian
[14:26] <ghostcube> if this is what u want no prob
[14:26] <ScottK> ghostcube: Ubuntu Studio supports Jack.
[14:26] <ScottK> For exactly this reason.
[14:26] <ghostcube> not working
[14:26] <ghostcube> its not an studio or kubuntu prob the lins are the same
[14:26] <ghostcube> *libs
[14:26] <ghostcube> i tried it
[14:27] <ghostcube> ui cant check jackd into phonon audio sources with xine backend
[14:27] <ghostcube> thats fact
[14:28] <persia> ghostcube, It's a known bug, and the main reason it's true is because we chose to support firewire audio with jack in preference to supporting the xine backend.
[14:28] <persia> For 9.04, this may no longer be a binary choice, and it can be resolved.
[14:28] <persia> Testing on this is not yet complete.
[14:28] <ghostcube> persia, thx for the answer
[14:29] <ghostcube> its not that i want to blame anyone ion here you do a great job
[14:30] <pitti> thekorn: I also filed a bug about using it in unauthenticated mode for public read-only operations
[14:30] <pitti> thekorn: for some strange reason I can't actually find the bugs I filed ATM, though :/
[14:31] <ghostcube> persia, as i see this screen i tried all to get this done :) and as no one could help the only chance was to get an answer here : http://dot.kde.org/1170773239/1170778900/1170862970/1170863051/kcmphonon5.png
[14:32] <persia> ghostcube, It's deliberately disabled.  It will be enabled if/when we can be confident of security support for the entire stack on which it depends.
[14:33] <ghostcube> persia, thx it would be a great thing for all the ones doing music on kde with ubuntu studio libs  :) thx and bye folks
[14:51] <thekorn> pitti, ok, cool, I've also found bug 302824, but I think I've already done something like this with the API,
[14:51] <thekorn> when I find it I will add a comment to this bug
[14:52] <pitti> ah, they got moved to the particular LP components, not launchpadlib any more
[14:53] <cjwatson> thekorn: can't you do it with archive.getPublishedSources? that takes a distro_series parameter
[14:53] <cjwatson> you can only get source package versions, not binary
[14:54] <thekorn> right, I've done:
[14:54] <thekorn> [i.source_package_version for i in u.main_archive.getPublishedSources(exact_match=True, source_name="apport", distro_series=ubuntu.current_series)][0]
[14:55] <cjwatson> right
[14:56] <pitti> thekorn: neat; could you post that to the bug report?
[14:57] <pitti> thekorn: thanks!
[15:03] <mterry> Hello! Any grub people in the house?  If I modify the grub package to add a new kernel option (add to defoptions in update-grub script), how do I make that new option active when update-grub runs during post-install?  update-grub seems to prefer existing menu.lst options.
[15:15] <stefanlsd> Would anyone mind checking if the debdiff - http://launchpadlibrarian.net/21011138/debdiff-jaunty-1  is a sane fix for a libtool error using autoreconf (never used it before...)
[15:25] <ogra> wow ... so i have a usb disk i manually mounted as root and untarred something on ... while that was running i plugged another usb disk into the same usb hub ... this caused the first disk to be remounted under /media/disk ... and indeed trashed my untar process
[15:25] <ogra> pitti, ^^^ ever heard of something like that ?
[15:25] <ogra> intrestingly the first mount was never really unmounted
[15:26] <pitti> ugh, "re"mounted?
[15:26] <pitti> no, never heared that
[15:26] <ogra> well, mounted
[15:26] <pitti> well, it was mounted before, wasn't it?
[15:26] <ogra> yes
[15:26] <ogra> and the devicename changed
[15:27] <ogra> i mounted /dev/sdb1 to /home/ogra/tmp
[15:27] <ogra> then plugged in the second disk to the same usb hub
[15:27] <ogra> and suddenly had a /dev/sdc1 (which in fact was sdb1 and now was mounted to /media/disk)
[15:28] <ogra> and a /dev/sdd1 on /media/disk-1
[15:28] <pitti> ogra: what does dmesg say?
[15:28] <ogra> additionally the terminal my tar xzvf was running in spilled I/O errors like mad
[15:28] <pitti> ogra: it sounds like if the first one suffered a temporary power loss or so
[15:29] <ogra> it has an external power supply
[15:29] <pitti> can you pastebin your dmesg?
[15:31] <ogra> pitti, http://paste.ubuntu.com/102215/
[15:33] <pitti> ogra: you have a disconnect at line 23, way before detecting the new drive
[15:34] <ogra> well, but that was caused by plugging in the second drive
[15:34] <pitti> ogra: that was the hub, I presume; line 47 is the actual (old) sdb
[15:34] <ogra> i could exactly see the tar errors starting the second i plugged it
[15:34] <pitti> which just went with the hub, I GUESS
[15:34] <ogra> weird ...
[15:35] <pitti> right, I don't doubt that
[15:35] <ogra> so dont buy intel hubs :P
[15:35] <pitti> it looks like pluggin gin the second disk disconnected the first one
[15:35] <ogra> actually that was a free giveaway ...
[15:36] <fbond> Hi, what recent Hardy update might've killed a colleauge's nvidia setup?
[15:40] <cody-somerville> fbond, not sure but I've heard other people complaining as well
[15:40] <apw> define killed?
[15:41] <fbond> apw: He's getting xorg log message that indicate that the a compatible kernel module can't be found ... ?
[15:41] <fbond> cody-somerville: Is there a package I can recommend he downgrade?
[15:41] <fbond> I've never dealt with the nvidia stuff so I'm short on answers.
[15:41] <apw> i woudl file a bug in launchpad with the errors you are getting
[15:42] <fbond> I get people in #ubuntu saying he should install the vendor driver.  Sounds like a bad idea to recommend that to a newbie...
[15:42] <apw> oh ... do you have to go into the hardware thing and reenable 'binary drivers' every time you get a new kernel.  i think someone said that to me once
[15:43] <cody-somerville> slangasek, It appears that there may be a regression. radix and fbond are both reporting issues with nvida after an update.
[15:43] <superm1> apw, no you shouldn't have to
[15:43] <fasta> Who decides whether any given piece of code goes into Ubuntu?
[15:43] <superm1> did lrm for hardy perhaps just not get onto the given mirror at the same time as the kernel perhaps?
[15:43] <radix> cody-somerville: I just had to reboot before I could restart X
[15:44] <pitti> apw, fbond: no, it should auto-upgrade
[15:44] <apw> fasta, the maintainers of the package in question
[15:44] <radix> cody-somerville: presumably because the new X driver was put into place before the kernel module was there, or something
[15:44] <cody-somerville> interesting
[15:44] <fbond> I understand my colleague has rebooted already.
[15:44] <fasta> apw: and when does someone qualify for being a maintainer?
[15:45] <apw> generally through the motu process
[15:45] <apw> just interested in how it works or trying to get something into a package?
[15:46] <fasta> !motu
[15:48] <fbond> Okay, so packages hit proposed and the changelog dates are mostly accurate.  But the changelog doesn't get updated when they move to -updates?  How can I tell when a package was released to -updates?
[15:50] <apw> https://edge.launchpad.net/ubuntu/+source/linux
[15:50] <apw> fbond, pages of that form exist for every package and i think that contains the info you want
[15:52] <fbond> apw: From what I can tell the relevant packages haven't been updated recently.  I'm really lost as to what might have caused a regression.
[15:53] <cjwatson> fbond: the associated bug reports are usually updated when a package moves to -updates
[15:53] <fbond> cjwatson: Okay.  All of this makes tracking down "what update occured recently that might've broken feature X" a bit difficult.
[15:54] <fbond> Be nice to have an RSS of SRUs...
[16:10] <kirkland> Riddell: hiya, could you have another look at screen-profiles, and see if the COPYING file I added to the tarball is sufficient?
[16:12] <Riddell> kirkland: I approved it yesterday
[16:12] <Riddell> it's probably in binary new now
[16:12] <kirkland> Riddell: rock on! thanks ;-)
[16:13] <Riddell> accepting binaries
[16:19] <lool> pitti: Re: MIRs, any opinion on promoting packages requiring special hardware (#309635)
[16:21] <pitti> lool: as you said, if a maintainer has the hw, that's fine (and if we don't want it, we should rather drop multipath-tools as well); however, dendrobates- might enlighten us whether we want to support it?
[16:24] <dendrobates-> pitti: the plan is to support
[16:24] <dendrobates-> pitti: the plan is to support  FC cards connecting to a SAN
[16:25] <pitti> dendrobates-: that translates to "multipath-tools"? (NB that I have no clue about those things)
[16:25] <pitti> dendrobates-: so if we have the tools, having installer support as well certainly makes sense then/
[16:25] <dendrobates-> pitti: we do not have installer support yet.
[16:25] <lool> dendrobates-: We're discussing promoting the installer support
[16:26] <pitti> dendrobates-: I think that's what bug 309635 talks about
[16:26] <lool> dendrobates-: The question is whether people will be able to test it / support it
[16:27] <dendrobates-> lool: more is required for installer support, but yes we are working with EMC to make sure we can test an support them.
[16:27] <pitti> dendrobates-: so what would you advise? wait with the MIR until we have full commitment/capacities/equipment?
[16:28] <dendrobates-> pitti: is there any harm in promoting it now?
[16:28] <fbond> cody-somerville, apw, et. al.: Issue resolved.  I can't say this is an Ubuntu regression.  User was installing some 3rd party packages that *may* have interfered with deps causing him to lose l-r-m.
[16:28] <fbond> Thanks all!
[16:28] <pitti> dendrobates-: is there any harm in promoting it later, when we can actually test it?
[16:29] <pitti> dendrobates-: promoting it now means to commit to it without being able to really support it, etc.
[16:29] <lool> pitti: Do you happen to know when multipath-tools was promoted?  I didn't find the MIR in a quick google
[16:30] <pitti> lool: ages ago; that was a fabbione-ism
[16:30] <lool> wow
[16:30] <dendrobates-> pitti: we can test it now,  Ettienne is going to emc in a couple weeks to start working.
[16:30] <pitti> dendrobates-: ah, that's my primary concern
[16:33] <pitti> thekorn: hm, seems I get this LaunchpadURLError in the retracer, too, on production; also sometimes from my own box
[16:33] <pitti> thekorn: so I guess it's not related at all to p-lp-bugs in the end
[16:34] <soren> It's kind of hard to test installer stuff that isn't in main, isn't it?
[16:36] <lool> soren: tjaalton wrote "They are available to test if universe udeb support is preseeded" I understand from that that one can use universe udebs
[16:37] <soren> I see. I did not know that.
[16:40] <pitti> thekorn: any idea why this happens? http://paste.ubuntu.com/102228/
[16:40] <pitti> thekorn: (indeed there is no /home/ubuntu-archive/.python-launchpad-bugs.conf in the chroot, but there shouldn't be; I set an explicit cookie file)
[16:41] <thekorn> pitti, sorry, connot look at it right now, will look at it later today
[16:41] <pitti> thekorn: no problem; thanks a log!
[16:41] <pitti> lot
[16:42] <thekorn> np. please post all tracebacks you get
[16:42] <pitti> thekorn: I have no clue about the LPUrlError, but this one at least looks fixable
[17:30] <slytherin> Can any archive admin please process bug 315081. It will clear solve least one other FTBFS.
[17:54] <Riddell> zul: is this mysql intended for main or universe?
[17:54] <zul> universe
[18:23] <superm1> pitti, ping.  regarding bug 314547, it sounds like hal might have started emitting events for some keypresses.  do you know of this functionality sneaking in one of the last RC's in jaunty, or possibly of a configuration option that got added to enable and disable it?
[18:32] <superm1> bryce, or perhaps is that (^) a side effect of X not taking an exclusive hold on the device anymore?
[18:35] <bryce> superm1: it's possible
[18:36] <superm1> if that's the situation, then i guess the proper solution is that gnome power manager shouldn't be intercepting the keypress anymore, but just listening for the dbus event
[18:37] <superm1> and for all other apps that start doing the same thing
[18:52] <RainCT> mvo: Hey
[18:53] <RainCT> mvo: Anything new regarding apturl? (By the way, there are one or two patches -from other people- in Launchpad)
[18:55] <mvo> RainCT: hello! let me check on them
[18:55] <mvo> (the patches)
[18:57] <RainCT> mvo: bug #304950, bug #304925
[18:58] <RainCT> mvo: Do you know if there's anything new on the policykit/packagekit front, or do you have any plans for a future version?
[19:02] <superm1> pitti, bryce, yeah i'm pretty sure that's what it is. i'm thinking more apps will start to react similarly.  i'm not sure how many different dbus events HAL knows how to send, so i dont know what apps will be affected
[19:05] <joe-mac> hey guys i was wondering if someone in here could possibly help with a preseed/d-i question? i'm trying to preseed raid, but partman-auto-red
[19:05] <joe-mac> raid*'s udeb is missing
[19:05] <joe-mac> i tried dropping it in with the other partman-auto-* udebs, to no avail. i am guessing i need to modify something. could someone opoint me to the doc this is outlined in or if simple enough tell me what to do
[19:06] <bryce> superm1: it sounds right, I'm also a bit uncertain as to how it all should work, but dbus feels like the way forward
[19:07] <slangasek> fbond: any luck figuring out what package changed to break nvidia?  as you note, none of the "relevant" packages have been updated recently on hardy
[19:07] <superm1> bryce, yeah i'm looking, and tons of the hotkeys i've got act that way (play, pause, stop, volume, brightness) where they send dbus events from hal and also keypresses to X
[19:09] <slangasek> superm1: hal emitting events for keypresses> well, if it's on a ThinkPad, see the hal changelog, yes
[19:09] <fbond> slangasek: I believe this was caused by a 3rd party package with interesting dependencies.
[19:09] <fbond> slangasek: No regression suspected.
[19:09] <superm1> slangasek, these are on dells
[19:09] <slangasek> if it's not a ThinkPad, I have no idea what changed that would affect it
[19:09] <slangasek> fbond: ah
[19:10] <superm1> slangasek, at some point bryce mentioned (maybe only to me, i dont remember  the context), that X doesnt hold an exclusive grab to keyboards anymore
[19:10] <fbond> slangasek: l-r-m had been removed.
[19:10] <superm1> so other apps (such as HAL) would allow to do stuff with the input device
[19:11] <slangasek> superm1: hmm, could be - and users wouldn't have reported this problem, the way it was reported for ThinkPads, if X were handling those keypresses
[19:12] <superm1> bryce, do you remember where that change was made regarding exclusive grabbing?  Is there anyway that upstream would be able to detect it's presence, so they know whether an app should grab keys or not?
[19:12] <slangasek> eew abstraction violation
[19:13] <slangasek> superm1: what we really want to do is fix it so X isn't generating keysyms for those keys
[19:13] <pitti> superm1: I didn't change any particular hal configs, no
[19:13] <slangasek> there's no reason for a single event to be propagated via both hal and X
[19:14] <pitti> superm1: but I noticed that suddenly F9 to F11 now control mute/volume in jaunty; but that got changed recently, something in latest GNOME?
[19:14] <superm1> slangasek, well the problem is some applications don't actually listen for the dbus events and some do i think
[19:14] <slangasek> doesn't matter?
[19:14] <slangasek> anything that doesn't listen for the dbus event needs fixed
[19:15] <pitti> superm1: AFAIK, hal does not send any key related d-bus events at all; the only thing that it does is to poke updated keysyms into the kernel table
[19:15] <slangasek> pitti: not true
[19:15] <superm1> yes i agree there, but that list needs to be made before this change is made for X
[19:15] <pitti> slangasek: oh? seems I still didn't understand it then
[19:15] <superm1> pitti, it's a recent thing for jaunty.  look at some of the logs in the bug i pointed above
[19:15] <slangasek> pitti: https://wiki.ubuntu.com/Hotkeys
[19:15] <lool> Folks, I just got a rejection in my ppa that "The source imagemagick - 7:6.4.5.4.dfsg1-1ubuntu2 is already accepted in ubuntu/jaunty", but rmadison doesn't list it and I don't see it on -changes
[19:16] <slangasek> hal-addon-input is still part of the design, it processes key events and produces dbus signals
[19:16] <pitti> oh, right, that
[19:16] <lool> And I don't see it in http://ftp.debian.org/debian/pool/main/i/imagemagick/ either
[19:17] <slangasek> you don't see -1ubuntu2 on a Debian mirror? :-)
[19:17] <lool> Err http://archive.ubuntu.com/ubuntu/pool/main/i/imagemagick/
[19:17] <lool> slangasek: :)
[19:17] <lool> EPASTE from my script
[19:17] <slangasek> lool: I don't see it in the done or accepted queuest, either; I'd suggest asking the LP folks
[19:17] <lool> slangasek: Ok thanks
[19:17] <pitti> slangasek: I thought h-addon-input was the thing that writes the hal-info keymaps into the kernel?
[19:17] <slangasek> the soyuz folks, specificall
[19:18] <slangasek> pitti: it may do that, as well - hal-setup-keymap is the component that actually does the poking, I don't know if that's invoked by hal or by hal-addon-input
[19:18] <mvo> RainCT: patches applied, thanks! I check the remaining ones
[19:19] <pitti> slangasek: ah, ok; I crawl back into my hole now
[19:20] <slangasek> pitti: anyway, the fact that some events are meant to be received by all sessions via dbus, and some events are meant to only be received by the current session via X, is covered in one of mjg59's blogs
[19:20] <slangasek> I unfortunately don't have that integrated into the hotkey documentation in the wiki yet :P
[19:20] <superm1> ah this is the reason that suspend and hibernate keys started working in jaunty properly now too then
[19:20] <slangasek> oh no, yes I do.  http://mjg59.livejournal.com/99754.html linked from https://wiki.ubuntu.com/Hotkeys/Architecture
[19:20] <RainCT> (OT, if someone knows an easy way to put something with transparency and the like on the desktop -preferably with Python, and without using gdesklets or other stuff like that- or knows some page with info on this matter please tell me)
[19:21] <RainCT> mvo: No problem. Remaining ones?
[19:21] <mvo> RainCT: remaining open bugs
[19:22] <mvo> RainCT: the unconfirmed ones, just checking if there is more that can be fixed before I upload
[19:22] <pitti> argh, what the heck happened to the mixer applet?
[19:24] <slangasek> superm1: which keys are the ones registering double-events?  it's possible that they don't belong on dbus at all because they should only be applied to the current session?
[19:25] <superm1> slangasek, right now only battery, but with a newer gnome power manager, it would be battery, suspend, hibernate
[19:25] <slangasek> right, I guess those are all reasonable to have over dbus
[19:25] <superm1> what are examples of ones that shouldn't be on dbus at all?
[19:25] <slangasek> media keys
[19:26] <slangasek> (I think)
[19:26] <slangasek> or volume keys; you don't want multiple sessions all trying to adjust the mixer
[19:26] <superm1> hm i kinda can see that - but what if you had multiple media players?
[19:26] <slangasek> apps can also listen for X events non-exclusively, I believe
[19:26] <slangasek> the X/dbus dichotomy is only about "current session" vs. "all sessions"
[19:27] <tedg> I believe that the new GPM now looks to console kit to ensure that it's in the current session before acting on HAL events.
[19:27] <tedg> I screwed up the packaging, so it's not packaged yet.
[19:27] <slangasek> superm1: also, g-s-d grabs a number of X events and turns them into dbus signals anyway :)
[19:28] <slangasek> but on the session bus where they belong
[19:28] <superm1> slangasek, yeah i think i like that model the best anyho
[19:35] <jdstrand> kees, mdeslaur: fyi-- I added README.multipurpose-vm to qa-regression-testing. The idea behind it is to have a multi-purpose server VM that other VMs or tests can interact with
[19:36] <jdstrand> kees, mdeslaur: this came about with my thunderbird testing, where I wanted to test pop3(s), imap(s), smtp, tls, etc
[19:36] <kees> cool
[19:37] <jdstrand> kees, mdeslaur: it just documents the email stuff for now, but I plan to add bind9 today, and kerberos and ldap when I have a chance
[19:37] <jdstrand> (read: 'not today' ;)
[19:37] <kees> heh
[19:39] <jdstrand> kees, mdeslaur: it focuses on hardy for now, because a) it isn't meant to be what is being tested and b) it's LTS
[19:39] <jdstrand> kees, mdeslaur: please add to it if appropriate
[19:40] <Cpudan80> Hello all
[19:40] <Cpudan80> Question
[19:40] <Cpudan80> I need to pull down a few packages from Jaunty repos
[19:40] <jdstrand> kees, mdeslaur: it would be particular nice to have the whole VM somewhere too, but somehow I think LP/bzr isn't the most efficient way to deal with a 4G binary blob
[19:40] <Cpudan80> Into my Intrepid installation
[19:40] <Cpudan80> How can I do that
[19:41] <pitti> thekorn: ok, it seems that http_connection.py, line 342, calls self.__config.save(), which unconditionally writes the file; I guess I can get away with just mkdir'ing /home/ubuntu-archive/ in the chroot
[19:42] <jdstrand> kees, mdeslaur: though a preseed/FAI/kickstart thingy could be very cool...
[19:48] <calc> doko_: ping
[19:49] <thekorn> pitti, yes this might me the easiest solution, but I always thought that writing to this config file is disabled by default and has to be enabled explicitly
[19:49] <doko_> calc: contentless pong
[19:49] <pitti> thekorn: I guess I just locally patched it out in the earlier chroots, and forgot
[19:50] <yao_ziyuan> the latest QtCurve 12/29/2008 (http://www.kde-look.org/content/show.php?content=40492) is so good that i recommend it be the default theme in ubuntu and kubuntu
[19:50] <calc> doko_: have you used db bahn before?
[19:50] <doko_> calc: db bahn?
[19:51] <calc> doko_: german train service (i think?)
[19:51] <pitti> www.db.de
[19:51] <calc> http://www.bahn.de/
[19:51] <doko_> calc: sure, it's *working*
[19:51] <pitti> unless they have to check their ICEs...
[19:51] <calc> ok, my question is there anything special with respect to luggage?
[19:51] <calc> i will be going between berlin and hamburg after the sprint
[19:51] <pitti> calc: no limitation
[19:52] <calc> ok
[19:52] <pitti> calc: you just have to find some space for it and not leave it in the aisle
[19:52] <pitti> calc: they have some special areas where to store bulky luggage, too
[19:52] <calc> ok i won't have much just a plane carryon plus small backpack
[19:59] <pitti> thekorn: ok, now I'm back to the LaunchpadURLError with "unknown error" on +editstatus
[20:00] <thekorn> pitti, can you please post me the traceback, when does it happen, when uploading an attachment?
[20:00] <thekorn> oh, editstatus
[20:01] <pitti> thekorn: see bug 300548
[20:01] <pitti> thekorn: it actually set the status, and added the attachments, an attached the comments
[20:01] <pitti> but then it crashes
[20:01] <pitti> thekorn: http://paste.ubuntu.com/102325/
[20:03] <thekorn> wait, it's a huge comment, if seen this in ubuntu-dev-tools recently
[20:04] <pitti> thekorn: I'll cut it in half, all the -dbgsym packages shouldn't appear in the comment anyway
[20:05] <rootard> doko_: I've tried using the sun-java6 source package as a base for the OpenSolaris .sh files. The source now "builds" but fails to produce a sun-java6-bin deb package
[20:05] <pitti> thekorn: the size of the comment matters? or is it the combination of adding a comment, attachments, and status changes?
[20:05] <rootard> any pointers on where this might be failing?
[20:06] <rootard> a debian/sun-java6-bin directory is created and populated
[20:07] <thekorn> pitti, bug 311289 comment #4 has a reproducer for +file-bug, let me try if it also "works" for comments
[20:09] <pitti> thekorn: that might be true, it's the first time I add comments of that size
[20:12] <pitti> hm, anyone who knows python's subprocess pipe handling?
[20:12] <pitti> $ python -c "import subprocess; subprocess.call(['cat', '/nonexisting'], stderr=subprocess.STDOUT)" > /dev/null
[20:13] <pitti> this should theoretically redirect cat's stderr to python's stdout and thus I shouldn't see any output
[20:13] <pitti> but I do see cat's error message on stderr
[20:13] <sebner> pitti: mind sponsoring some mono-* rebuilds?
[20:13] <pitti> sebner: I'm currently a bit overloaded, I'm afraid, so not right now
[20:13] <sebner> pitti: kay, np
[20:16] <pitti> bah, if I set "stdout=sys.stdout", it works; I thought that were the default anyway..
[20:17] <cjwatson> doesn't really work, drop the >/dev/null to see the new error
[20:17] <cjwatson> oh, stdout=sys.stdout not stderr=sys.stdout
[20:17] <pitti> cjwatson: I tried that, seems to work fine
[20:18] <pitti> right, stdout=sys.stdout, stderr=sys.stdout blows up
[20:18] <pitti> but stderr=subprocess.STDOUT properly merges them
[20:18] <cjwatson> I think that stderr=subprocess.STDOUT means "capture to the same file handle as stdout, but only if stdout is being captured rather than passed through
[20:18] <sianis> cjwatson: can you commit bug 293356?
[20:18] <cjwatson> sianis: no
[20:18] <cjwatson> (well, I can, but why me?)
[20:18] <sianis> cause you have right
[20:19] <cjwatson> so do several dozen others
[20:19] <sianis> and you are the last person in the changlog
[20:19] <cjwatson> sianis: the proper way to do it is to subscribe ubuntu-main-sponsors, not to hassle individuals
[20:19] <pitti> sianis: please subscribe ubunt-main-sponsors
[20:19] <sianis> okey
[20:19] <sianis> thanks
[20:19] <cjwatson> then it goes into a queue where people who are in the mood to do sponsorship right now can do it
[20:20] <cjwatson> rather than somebody who's about to head off and do other things for the evening :-)
[20:24] <sianis> ok, thank you
[20:30] <pitti> thekorn: in another bug it already crashed in the Bug() ctor already: http://paste.ubuntu.com/102338/
[20:30] <pitti> thekorn: it looks like this intermittently happens in LP itself?
[20:30] <Baby> pitti: hi! :)
[20:31] <pitti> Baby: hello
[20:31] <Baby> are you very busy?
[20:32] <pitti> Baby: actually yes, I'm afraid, but don't hesitate to ask
[20:32] <Baby> oki, I'm gonna upload the package, but I'm not sure how to update the bzr repo after that
[20:33] <pitti> Baby: dch -r will change UNRELEASED to "unstable"
[20:33] <pitti> Baby: then you debuild
[20:33] <Baby> aha oki :)
[20:33] <Baby> and after that I push?
[20:33] <pitti> Baby: and then finally "debcommit -r", which will commit the UNRELEASED->unstable change with a standard comment, and add a tag for the version number; then just 'push'
[20:33] <Baby> sorry, commit and push?
[20:33] <Baby> oki :)
[20:34] <Baby> thanks :)
[20:34] <pitti> Baby: "debcommit -r" is essentially: bzr commit -m 'release as 0.1.2-3'; bzr tag 0.1.2-3
[20:34] <pitti> but easier to use
[20:34] <thekorn> pitti, these tracebacks are ugly, I wish py-lp-bugs could be more verbose there, but I think this looks like "internal server error" or samoething
[20:34] <pitti> Baby: (and also works with svn, cvs, and whatnot)
[20:34] <Company> pitti: are there plans to make dbgsym packages contain sources, so that i know more than that the code crashed in gtkrange.c:1242
[20:34] <Baby> thanks pitti, that should be enough :)
[20:34] <Company> pitti: in a way that doesn't involve lots of manual labor?
[20:35] <pitti> thekorn: that happens after while count < self.__attempts: apparently? I. e. after three failed attempts?
[20:35] <thekorn> pitti, yes, exactly
[20:35] <pitti> Company: I don't currently plan that, they would get even bigger that way
[20:35] <pitti> Company: I have a feature for including source in apport, it's just not currently enabled
[20:36] <pitti> thekorn: it looks like the same happened to me locally with staging; maybe it is a tad slower than production and thus times out more easily
[20:36] <Company> pitti: i want it for my own debugging - and i'd be happy with some apt config that would make it auto-download/delete sources and put them somewhere sane
[20:37] <pitti> thekorn: is there any knob I could turn to increase the timeout?
[20:37] <pitti> Company: I think we should rather make the source links more sane, so that apt-get source'ing into /usr/src or so would DTRT
[20:37]  * slangasek snorts at edge.  "Your languages: Inuktitut, Spannish, Yiddish"
[20:37] <thekorn> pitti, sorry, not that I know of
[20:38] <pitti> slangasek: I *knew* you were good at foreign languages! :-)
[20:38] <Company> pitti: should i file a bug about it? (and if so, which package?)
[20:38] <slangasek> pitti: those aren't the languages I selected. :)
[20:38] <slangasek> meshuggene edge!
[20:39] <pitti> Company: not sure whether it's doable with the GNU debug links in ELF; but file it against pkg-create-dbgsym for now
[20:40] <pitti> thekorn: can I raise the default value of attempts=5?
[20:40] <slangasek> ah, strangely it was showing me those languages because I wasn't logged in. errr?
[20:41] <thekorn> pitti, no, unfortunatly not
[20:42] <james_w> pitti: thekorn: http://bazaar.launchpad.net/~james-w/python-launchpad-bugs/urlerror-reason/revision/172
[20:42] <james_w> that might make the error you are getting more clear
[20:43] <pitti> oh!
[20:43] <james_w> launchpad does like to refuse connection from time to time though, often with 502
[20:43] <pitti> yesterday it worked like charm, and today it's so totally misbehaving
[20:43] <LaserJock> cjwatson: is people.ubuntu.com/~cjwatson still the canonical branch for debian-cd in Ubuntu?
[20:45] <pitti> thekorn: the network connection from ronne is utterly slow in general (don't know why), so that might contribute to it
[20:46] <james_w> staging is also a single machine as I understand it
[20:46] <thekorn> pitti, my problem right now is: I can't reproduce any of these bugs, so it is hard to debug
[20:46] <pitti> thekorn: right, and I'm more and more convinced that it's not a p-lp-bugs problem anyway; thanks a lot for your help!
[20:50] <thekorn> pitti, np, the problem of py-lp-bugs is that is such a hard to debug, non verbose, hackish beast... so thanks for using it ;)
[20:59] <pitti> james_w: AttributeError: 'exceptions.AttributeError' object has no attribute 'reason'
[21:00] <james_w> pitti: huh
[21:00] <thekorn> AttributeError, wtf? - then it's py-lp-bugs
[21:00] <james_w> that's my fault, sorry
[21:00] <pitti> thekorn: it just tries whether e.code exists, if not, it's "unknown error"
[21:01] <james_w> it overwrites the original error when it catches the AttributeError, should have seen that
[21:01] <pitti> james_w: oh, of course
[21:01] <pitti> james_w: I'll rename it
[21:01] <james_w> fixed in my lp branch
[21:03] <pitti> james_w: you just removed the ", e" in the inner except?
[21:03] <pitti> right, now loggerhead caught up
[21:03] <james_w> yup
[21:04]  * pitti turns the crank again
[21:04] <pitti> but I bet these are just ordinary LP timeouts
[21:06] <Baby> pitti: I've made some modifications and added the man pages that were missing, I still don't know how to solve one of the lintian warnings with cdbs
[21:06] <Baby> W: calibre: desktop-mimetype-without-update-call /usr/share/applications/lrfviewer.desktop
[21:07] <pitti> Baby: ah, needs call of dh_desktop, I figure
[21:07] <pitti> Baby: that'll cause postinst code to call update-desktop-database
[21:08] <Baby> it should give the same error for calibre.desktop too, I guess
[21:08] <Baby> in any case, with cdbs I don't have a clue where to put the dh_desktop
[21:09] <pitti> Baby: should go into binary/calibre::
[21:09] <pitti> I wonder why cdbs doesn't just call it
[21:09] <pitti> Baby: ah, gnome.mk and kde4.mk call it automatically
[21:09] <pitti> Baby: but the latter doesn't exist in Debian
[21:09] <Baby> ah I see
[21:10] <pitti> (and would be more appropriate for a Qt program)
[21:10] <pitti> Baby: so please add
[21:10] <pitti> binary-install/calibre::
[21:10] <pitti>        dh_desktop
[21:10] <pitti> that should do
[21:10] <Baby> dh_desktop or dh_desktop -pcalibre ?
[21:10] <pitti> Baby: right, your's
[21:10] <pitti> aah
[21:10] <pitti> launchpadbugs.exceptions.LaunchpadURLError:
[21:10] <Baby> oki :)
[21:11] <pitti>     * message: The read operation timed out
[21:11] <pitti>     * url: https://bugs.launchpad.net/bugs/303022
[21:11] <pitti> thekorn, james_w: ^
[21:11] <pitti> thekorn: so not your fault :) but maybe merge james_w's branch, it's nice for debugging
[21:11] <james_w> pitti: ouch
[21:11]  * pitti hugs james_w
[21:11]  * james_w hugs pitti
[21:11] <james_w> no launchpad love for apport
[21:11]  * thekorn hugs pitti , gottseidank
[21:11] <thekorn> and james_w
[21:12] <pitti> meh, I just finished the implementation for unbreakable-retracer, and now LP crashes underneath me...
[21:19] <Baby> pitti: duploading
[21:21] <Baby> shit, I did the debcommit before adding the new files
[21:24] <pitti> thekorn: in a way I hoped it was something we could circumvent in p-lp-bugs; now I'm quite at loss :/
[21:27] <thekorn> pitti, yeah, right :( seriously switch apport over to lplib, it is a lot faster these days, and maybe more stable
[21:27] <thekorn> maybe I should start an apport branch
[21:28] <pitti> thekorn: I guess that's what I'll have to do in the end
[21:28] <pitti> thekorn: I just can't use it on the client side, since it insists on login credentials, but on the server side it should be quite alright
[21:30] <slangasek> james_w: is there a sane way that we could make bzr builddeb automatically set a "right" -v option to dpkg-buildpackage when doing a merge from Debian via bzr?
[21:31] <james_w> slangasek: it could guess, but it's not going to be reliable, so it's perhaps best not to rely on it
[21:32] <slangasek> hmm
[21:32] <james_w> at least I can't think of a reliable algorithm
[21:32]  * slangasek nods
[21:33] <thekorn> pitti, right, anonymous  "read-only" login would be cool
[21:33] <james_w> it's easy to work out what the -v and -sa should be if you know it's a merge though
[21:33] <slangasek> unfortunately, that means that presently I lose out on the benefit of MoM's auto-generated genchanges script for packages that I'm merging via bzr, and consequently often fail at passing the correct -v myself
[21:33] <slangasek> james_w: so if there were an option like 'bzr builddeb --is-merge' or something?
[21:34] <james_w> it could do it
[21:34] <james_w> I'm leaning more to restructuring the way it works though, we keep hitting things like this *all the time*
[21:36] <james_w> often there is nothing stopping you from just using debuild or whatever though
[21:44] <slangasek> james_w: does debuild automatically exclude .bzr?
[21:44] <slangasek> <-- lazy
[21:44] <ScottK> lazy/trying to be efficient.
[21:44] <james_w> slangasek: debuild does
[21:45] <james_w> slangasek: I *think* dpkg-buildpackage might even now
[21:45] <slangasek> ScottK: yes, laziness is a virtue, I didn't mean to imply anything different ;)
[21:45] <ScottK> OK, just trying to clarify.
[21:45] <pitti> slangasek: debuild -i
[21:46] <pitti> slangasek: and -I.bzr for excluding them from built tarballs (native packages)
[21:46]  * pitti uses alias debuild='debuild --preserve-envvar PATH -i -I.bzr -I.svn -I.shelf'
[21:46] <superm1> pitti, environment variable form: DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i'(?:^|/).*~$|(?:^|/)\..*\.swp|DEADJOE|(?:/CVS|/RCS|/\.svn|/\.deps|\{arch\}|\.arch-ids|\.arch-inventory|\.bzr|\.bzrignore|\.shelf)(?:$|/)' -ICVS -I.svn -I\{arch\} -I.arch-ids -I.arch-inventory -I.bzr -I.bzrignore -I.shelf"
[21:46] <superm1> someone posted that at some point
[21:47] <slangasek> pitti: the part where I have to type extra options afterwards is the part that annoys me :)
[21:47] <pitti> slangasek: which is why I'm using an alias :)
[21:47] <slangasek> s/type/configure on all my systems/, then
[21:48] <slangasek> if everyone agrees it's the only sensible thing to do, we should make it the default
[21:48] <slangasek> we have the source ;)
[21:48] <pitti> slangasek: well, you are in -core-dev, upload a fixed default :)
[21:48] <pitti> (snap)
[21:51] <tjaalton> I've noticed that dpkg-buildpackage no longer excludes .git in jaunty
[21:51] <slangasek> I guess dpkg-buildpackage has no way to override a -i or -I option once set, though, so it's not the appropriate place to make the change?
[21:52] <slangasek> (nor dpkg-source)
[21:54] <pitti> thekorn: argh, while installing launchpadlib as normal user in a small development chroot, I appreciate how easy it is to use/install p-lp-bugs...
[22:01] <pitti> thekorn: launchpadlib doesn't seem to work at all on ronne's restricted network access; bummer
[22:07] <calc> cool the OOo bugwatch lp stuff got fixed today it seems
[22:07] <calc> all of my bugs status got updated
[22:08] <pitti> I got a flood, too
[22:10] <pitti> good night everyone
[22:10]  * pitti gives up and hopes that ronne will behave better tomorrow
[22:11] <pochu> 'night pitti
[22:29] <cjwatson> pitti: there's a sensible default now if you just say -I
[22:29] <slangasek> cjwatson: passing that to dpkg-buildpackage?
[22:29] <cjwatson> yes
[22:29] <slangasek> \o/
[22:30] <cjwatson> well, -i -I
[22:30]  * slangasek nods
[22:30] <cjwatson> LaserJock: yes
[22:30] <LaserJock> cjwatson: k, thanks
[22:32] <slangasek> kirkland: could you provide a transcript of a session showing bug #305882?
[22:32] <slangasek> the description ("attempt to change", "actually change") is somewhat unclear to me
[23:26] <kirkland> slangasek: sure, setting it up now
[23:45] <kirkland> slangasek: hmm, i actually was unable to reproduce 305882, when trying just now ... i marked it "Incomplete", providing a transcript, and asking the reporter to do the same
[23:45] <slangasek> ok :)
[23:46] <kirkland> slangasek: my apologies for slinging blame :-)
[23:46] <slangasek> oh, I don't doubt that we have other bugs there and I accept total blame for them - I just would like to not be trying to fix them blindly :-)
[23:47] <kirkland> slangasek: fair enough!