[06:58] <stochastic> Can someone take a look at this   http://revu.ubuntuwire.com/p/a2jmidid
[08:01] <dholbach> good morning
[08:07] <stochastic> hello, just curious if anyone can help me troubleshoot this error: http://pastebin.ubuntu.com/254295/
[08:11] <iulian> Morning dholbach.
[08:12] <dholbach> heya iulian
[08:17] <slytherin> superm1: ping, any idea how can I debug bug #414509 ?
[08:19] <superm1> slytherin, sorry i'm not familiar with the nautilus-sendto code
[08:19] <slytherin> ok
[08:19] <superm1> slytherin, but i would suspect you probably want to make sure your phone is offering the right services
[08:19] <superm1> some phones dont advertise all the obex services at all times
[08:20] <slytherin> Yes it does. I have used it in the past.
[08:20] <superm1> Ok. then that can be ruled out.  At least figure out the service identifier that your phone uses for obex then, and that's a starting point to look at the nautilus send to code
[08:21] <superm1> (there are a few different ones for obex)
[08:21] <superm1> you can use sdptool to query these
[08:21] <slytherin> I am thinking that the problem is with nautilus-sendto. Why don't I see the 'bluetooth plugin initilised' message.
[08:23] <superm1> you can use sdptool to query these
[08:23] <superm1> oops.  i was meaning to say you should probably forward this upstream
[08:23] <superm1> is that upstream pretty responsive about these kinds of bugs?
[08:41] <slytherin> superm1: I will forward upstream if I know what the root cause is. Looking into nautilus-sendto code I found out that there are three conditions that may cause the plugin initialization to fail. Two of them are related to dbus. And I don't understand dbus very well.
[08:59] <happyaron> hi, how about your discussion on tor yesterday?
[09:38] <kkaji`>  http://www.lostworlds.lv/go.php?1139723800 NEW WEBSITE GAME,COME AND PLAY.
[10:40] <stochastic> hello, just curious if anyone can help me troubleshoot this error: http://pastebin.ubuntu.com/254295/  Is it a bug in libqt4-dev ?
[10:41] <happyaron> freeflying: it's not very easy to get upstream happy on topic of tor as I was discussed with somebody in #tor
[11:22] <kaushal> hi
[11:23] <kaushal> I am running Hardy and i have collectd running collectd |    4.3.0-1 | hardy/universe | source, amd64, i386
[11:23] <kaushal> there are bugs in this version, as reported at #collectd
[11:23] <kaushal> so it has been fixed in 4.7 version of collectd
[11:23] <kaushal> can i have 4.7 version of collectd ?
[11:23] <Laney> Karmic has 4.6
[11:24] <Laney> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541887
[11:24] <kaushal> http://collectd.org/download.shtml
[11:25] <kaushal> Laney: can i have a .deb of 4.6 of collectd ?
[11:25] <kaushal> for Hardy ?
[11:26] <andv> kaushal, you should request a backport in that case
[11:26] <Laney> !backport
[11:26] <andv> kaushal, we cannot provide you random .debs files
[11:26] <Laney> try that procedure
[11:27] <andv> kaushal, or wait debian to package 4.7 and then ask the backport
[11:27] <andv> which should be the best way
[11:27] <andv> without having us to backport 4.6 then 4.7
[11:27] <slytherin> kaushal: or you can file bugs you are facing on launchpad and the fixes for those bugs can be backported to hardy if possible.
[11:27] <Laney> heh
[11:28] <andv> lol
[11:28] <kaushal> andv: so if use backport, i should be getting 4.6 :) ?
[11:28] <andv> kaushal, you should get karmic's version which is 4.6
[11:28] <kaushal> ah great
[11:28] <slytherin> andv: What was that LOL about?
[11:29] <andv> kaushal, but as I said, it's better to wait 4.7
[11:29] <andv> from debian then ask the backport
[11:29] <andv> slytherin, about your phrase
[11:29] <andv> :)
[11:30] <kaushal> andv: do you want me to ask #debian ?
[11:30] <Laney> no, don't
[11:31] <slicer> Is requestsync broken on karmic at the moment? It seems to just hang without any output at all.
[11:31] <andv> kaushal, no, the maintainer said it will be ready in the next few days
[11:31] <Laney> what are you trying to sync?
[11:32] <andv> kaushal, so just follow up debian bug @541887
[11:32] <Laney> Don't
[11:32] <Laney> Just keep an eye on the Debian page and then tell us when it's out
[11:32] <andv> Laney, that's what I said
[11:32] <Laney> I thought you were telling him to post there
[11:33] <andv> kaushal, when the upload is published follow the backport procedure and that's all
[11:33] <andv> Laney, no no :)
[11:33] <andv> Laney, the maintainer said the package is ready so
[11:33] <Laney> quite
[11:33] <slicer> Laney: If that was to me, I'm tryint to requestsync mumble from unstable :)
[11:33] <Laney> slicer: /me tries
[11:34] <Laney> ooh bug
[11:35] <slicer> Laney: Ah, so it's not just me then.
[11:35] <Laney> nah, that was a different bug
[11:35] <Laney> requesting the sync works fine
[11:35] <slicer> Laney: Oh. Then it IS me. *Sigh*
[11:35] <Laney> (requestsync --lp mumble)
[11:35] <geser> works for me too
[11:35]  * Laney didn't file it
[11:36] <Laney> geser: try requestsync --lp mumble karmic
[11:36] <Laney> http://dpaste.com/81617/
[11:36] <geser> I tried both with and without --lp, and both works
[11:36] <slicer> Laney: That's exactly what I did, and it just sits there doing nothing. *scratches head*
[11:37] <mok0> Excuse me for stupid question: what package contains /usr/bin/java ??
[11:37] <slicer> Maybe it's the network connection here, I'll try again when I get home.
[11:38] <Laney> mok0: isn't it managed by alternatives?
[11:38] <mok0> Laney: ah, yes, my alternatives are broken
[11:38] <mok0> Laney: thanks
[11:38] <Laney> np
[11:39] <mok0> My alternatives broke during a prior update, and it's been bugging me ever since
[11:39] <kaushal> andv: Thanks a Lot
[11:39] <kaushal> i did added deb http://archive.ubuntu.com/ubuntu hardy-backports main universe multiverse restricted
[11:39] <kaushal> and did apt-get update
[11:40] <kaushal> but it still shows the old version ?
[11:40] <kaushal> aptitude changelog show collectd
[11:40] <andv> kaushal, you didnt get the point then :)
[11:40] <slicer> Ok, requestsync works over a tunnel, so that was just a network problem.
[11:40] <andv> kaushal, first of all you need debian to upload latest 4.7 release
[11:41] <andv> kaushal, then YOU ask the backport
[11:41] <Laney> (sync)
[11:41] <kaushal> andv: i was referring to 4.6 :)
[11:41] <kaushal> and not 4.7
[11:41] <slicer> However, it's pulling the version from unstable (1.1.8-3), but the changelog is from experimental (which is version 1.2.0~something).
[11:41] <geser> Laney: can you reproduce the requestsync crash? from the traceback it looks like it crashed in processing the rmadison output, so it shouldn't matter if you use --lp or not
[11:41] <andv> kaushal, it's a non-sense asking the backport of 4.6
[11:41] <Laney> geser: no, seems transient
[11:41] <andv> when we gonna have 4.7 soon
[11:41] <Laney> but we should handle it and give an error instead of the trace
[11:42] <geser> as I assumed, rmadison (or the other side of it) has sometimes a small hickup
[11:42] <kaushal> andv: ah got it
[11:42] <slytherin> geser: Laney: I was having problem with requestsync 2 days ago. But I believe that problem was when trying to retrive information from Debian side.
[11:42] <Laney> a lot of Debian was down over the weekend
[11:42] <kaushal> so the steps are the same ?
[11:42] <slytherin> Also Debian PTS was not accessible for two days.
[11:43] <andv> kaushal, let's wait debian for 4.7 then we sync the package
[11:43] <andv> then we ask the backport
[11:43] <kaushal> andv: if there is a 4.7 version then i need to add deb http://archive.ubuntu.com/ubuntu hardy-backports main universe multiverse restricted and apt-get update ?
[11:43] <kaushal> and then run aptitude changelog show collectd ?
[11:44] <andv> kaushal, when the 4.7 is backported you can install it
[11:44] <andv> via apt-get
[11:44] <andv> adding hardy-backports in your sources.list
[11:44] <andv> as you already did I guess
[11:44] <happyaron> hey, I've added a comment on that bug I reported related to Tor
[11:44] <slicer> Auhm. Is there a way I can force requestsync to fetch the correct changelog? :)
[11:45] <kaushal> andv: so the command aptitude changelog show collectd will show 4.7 version ?
[11:45] <slytherin> slicer: what do you mean by 'correct changelog'?
[11:46] <slicer> slytherin: Try 'requestsync --lp mumble karmic'. It creates a request sync for 1.1.8-3 (unstable), but pulls the changelog from 1.2.0~something (experimental).
[11:46] <andv> kaushal, ye
[11:46] <kaushal> andv: great
[11:46] <kaushal> andv: so another 3-4 days ?
[11:47] <andv> depends from Debian and from you
[11:47] <andv> to ask the backport
[11:48] <slicer> slytherin: I want 1.1.8-3, it fixes a crashbug in karmic. I really don't want 1.2.0~blah, sice it's in "experimental" for a good reason :)
[11:48] <andv> kaushal, are you sure you understood all I said?
[11:48] <slytherin> slicer: that may not be requestsync's fault, Still you can try 'requestsync -d unstable --lp mumble karmic'
[11:48] <andv> kaushal, if not just tell me to explain again, np
[11:49] <kaushal> andv: sure, I have a question
[11:49] <slicer> slytherin: Same result. http://packages.debian.org/source/sid/mumble shows the correct changelog though.
[11:50] <kaushal> so what i understand is that 4.6 too is not backported in Hardy ?
[11:50] <kaushal> for example
[11:50] <kaushal> I know its not needed
[11:51] <andv> 4.6 is NOT backported to hardy
[11:51] <andv> coz it's we gonna have 4.7 soon
[11:51] <andv> so it's a non-sense/time-loss to backport 4.6
[11:51] <kaushal> andv: Understood now
[11:51] <slytherin> slicer: the url being used to retriev changelog  is http://packages.debian.org/changelogs/pool/main/m/mumble/current/changelog.txt I suggest that you wait for a day.
[11:51] <andv> kaushal, perfect :)
[11:52] <andv> kaushal, when 4.7 is in debian, ask to have it synced in ubuntu
[11:52] <andv> kaushal, then follow backport procedure
[11:52] <Laney> slytherin: We could use pkg_version instead of current
[11:52] <andv> !backports
[11:52]  * Laney tries to change it
[11:52] <kaushal> andv: if i have questions i will definetly ask :)
[11:53] <andv> kaushal, feel free to ping me if needed
[11:53] <slicer> Laney: Send me a diff if you can get it to work? :)
[11:53] <kaushal> andv: is there a way to know when and which application are backported to Hardy ?
[11:54] <andv> kaushal, subscribe to backports ML
[11:54] <kaushal> ah thats a Huge Traffic ML :/
[11:54] <andv> not really huge traffic
[11:55] <slytherin> backports ML is huge traffic?
[11:55] <andv> nope
[11:55] <andv> that's not what I call huge traffic
[11:55] <andv> *-changes is
[11:55] <andv> but not backports ML
[11:55] <andv> kaushal, anyway you gonna ask the backport yourself
[11:56] <andv> so you gonna be subscribed to the bug you wanna know about
[11:56] <kaushal> got it
[11:57] <andv> :)
[11:57] <andv> kaushal, I guess you'll have tons of questions when you will have to ask the sync
[11:57] <andv> and the backport
[11:57] <andv> so please read the wiki pages related to those processes
[12:03] <Laney> slicer: pushed, please test
[12:05] <slicer> Laney: Ah. Pull from where? :)
[12:05] <Laney> lp:ubuntu-dev-tools
[12:08] <slicer> Laney: Excellent :) Request sent. Thank you :)
[12:09] <Laney> no worries
[12:12] <slytherin> Laney: Who maintains reverse-build-depends script?
[12:15] <jpds> slytherin: The MOTU, but it looks like ryanakca last worked on it.
[12:15] <siretart`> has anyone fun with debugging strange dependencies that confuse apt to hell? this is blocking my next ffmpeg upload and I'd really like to read some feedback on that...
[12:16] <slytherin> jpds: hmm, in jaunty it assumes presence of jaunty source lists. I wonder why. If you simply look for '.*_dists_.*_.*Sources' instead of '.*_dists_jaunty_.*Sources'
[12:16] <slytherin> s/if you/it should/
[12:17] <slytherin> siretart`: do you have error log somewhere?
[12:17] <jpds> slytherin: Seems to look for my $source_pattern = ".*_dists_karmic_.*Sources\$"; in karmic..
[12:18] <slytherin> jpds: Yes. It is a problem then. I mean I can have the source lines for debian unstable, but they will not be used.
[12:19] <jpds> slytherin: Might be worth filing a bug about.
[12:19] <slytherin> I will.
[12:20] <siretart`> slytherin: in a VM, add "deb http://ppa.launchpad.net/siretart/ppa/ubuntu karmic main" and type 'sudo apt-get install vlc ubuntu-restricted-extras'
[12:20] <slytherin> siretart`: ahh, I don't have access to any VM right now. :-(
[12:21] <siretart`> slytherin: in my tests, apt fails to find a valid solution for this problem. however, there *is* a solution which can be found by manually selecting the right (the -extra- and -unstripped- variants of libavcodec and libavutil)
[12:21] <siretart`> ok
[12:23] <siretart`> I *believe* that if I change the shlibs file and rebuild all reverse dependencies, apt would find the solution easier
[12:23] <ryanakca> slytherin: Sorry, please fix it up if you want, I haven't touched it in aeons
[12:23] <siretart`> but I'd really like to have some comments if what I'm doing is at least a bit sane
[12:24] <slytherin> ryanakca: I could fix it, but not very familiar with bzr. :-)
[12:25] <ryanakca> slytherin: ah. You'll get the hang of it soon enough... pretty much change && bzr commit -m "Your message" && bzr push lp:~slytherin/project/branch_name and get someone to merge it into lp:project ;)
[12:25] <slytherin> hmm will try when I go home.
[12:26] <slytherin> james_w: thanks for java3d sync. :-)
[12:26] <ryanakca> Anyways, good luck and thanks. I'm off to work :)
[12:37] <c_korn> why is the diff.gz recreated at the beginning of the build process ? http://pastebin.com/d16d29c99
[12:49] <azeem> c_korn: likely because you asked dpkg-buildpackage about doing so (maybe through some tool)
[12:56] <slytherin> c_korn: where do you see it being recreated?
[12:58] <c_korn> in line 33. it does not happen for all packages. for some packages after the debian/rules clean target immediately the debian/rules build target is called without recreating the diff.gz. and I was not able to determine the difference which makes the diff.gz recreate
[13:04] <slytherin> c_korn: I don't think it is rebuilding .diff.gz.
[13:05] <james_w> NBS is pretty big currently if anyone fancies some transitions
[13:05] <Laney> mmm transitions
[13:08] <c_korn> slytherin: it is rebuilding it. I can clearly see the tarball being untared again and the diff being receated
[13:09] <Laney> huats: Do you plan on updating glom?
[13:10] <slytherin> c_korn: is that 'dpkg-buildpackage -b' in correct place?
[13:10] <slytherin> line 28
[13:13] <c_korn> slytherin: hm, I don't know where it is coming from. maybe just some odd sbuild bug
[13:23] <huats> Laney: hum you told me you were doing it :(
[13:23] <huats> hum...
[13:23] <huats> there is  a misunderstand there I think
[13:23] <Laney> hah
[13:23] <Laney> I thought you were
[13:23] <Laney> ¬_
[13:24] <huats> :(
[13:24] <huats> go ahead if you want hen
[13:24] <Laney> i'll put it on the list
[13:24] <slytherin> asac: Two questions. 1. Is there any plan to update obexd to latest upstream version? 2. Is libgeoclue-dev going to be moved to main? If not it needs to be removed from build-dep of gnome-bluetooth.
[13:35] <dholbach> Ampelbein: thanks :)
[13:36] <Ampelbein> dholbach: ;-) no problem.
[13:37] <c_korn> if I know that sources cannot be compiled for some architecture is there some way to prevent it from building. or is the usual approach to just wait until it crashes?
[13:37] <slytherin> damn, javadoc is horribly slow on powerpc.
[13:38] <slytherin> c_korn: the architecture field in control file.
[13:43] <slytherin> james_w: there are two copies of libstax-java source in new queue. Can you please nuke one of them?
[13:43] <james_w> does it matter which?
[13:44] <Laney> yay
[13:44] <Laney> cdbs works once more
[13:47] <slytherin> james_w: I don't know. It is a new package synced from Debian. And I am not sure who synced which one.
[13:47] <james_w> should be identical then
[13:47] <slytherin> james_w: sizes do not look different.
[14:04] <asac> slytherin: not yet decided. i think we should do the mir for libgeoclue-dev
[14:04] <asac> thanks for spotting it btw
[14:04] <asac> slytherin: if you want to update obexd to latest give it a short
[14:05] <slytherin> asac: Ok. Will try tonight.
[14:05] <asac> thx
[14:24] <slicer> Can you no longer see the list of subscribers to a bug on launchpad?
[14:24] <sistpoty|work> hi folks
[14:25] <Laney> hihi
[14:25] <Laney> slicer: you can
[14:26] <sistpoty|work> just FYI: revu will be down for a few minutes (kernel upgrade)
[14:26] <Laney> damn 'sploitz
[14:26] <sistpoty|work> yep
[14:26] <Laney> I should restart my vps really
[14:27] <slicer> Laney: Aha. Er. How? I just subscribed ubuntu-universe-sponsors to my bug, but it's not listed anywhere on the bug page.
[14:28] <Laney> slicer: It's where it always was... on the right
[14:28] <Laney> seems ajaxified though, dunno how well it degrades
[14:29] <slicer> Laney: Now you know; it doesn't :) Change of browser fixed it.
[14:30] <Laney> slicer: get filin' a launchpad bug about that
[14:37] <slytherin> slicer: or better, fix launchpad code yourself. :-)
[14:38] <slicer> slytherin: AJAX? JavaScript? UI stuff? Pass :)
[14:42] <blackmoon> hi i i've make a deb package with a firmware (redistribution permitted but no source code available) for a usb wireless card, can i upload it on my ppa?
[14:43] <james_w> blackmoon: #launchpad will be able to tell you that
[14:43] <blackmoon> ok, thank you james_w
[14:45] <blackmoon> another thing, lintian gave me an "internal error: command failed with error code 123" anyone know someting about it?
[14:45] <james_w> blackmoon: what were the messages just before that?
[14:46] <Laney> alright LP, I get the idea, the package is broken
[14:46]  * Laney hisses
[14:47] <blackmoon> james_w: Now running lintian...
[14:48] <james_w> hmm
[14:48] <james_w> I'm not sure
[14:48] <james_w> I think there are debug flags to get it to tell you everything it is doing
[14:48] <blackmoon> james_w: but i think that it's not a problem no more, because the guy in #launchpad say me that i can't upload a binary packages...
[14:49] <james_w> lintian -d
[14:50] <happyaron> geser: I added a comment on that bug
[14:50] <bddebian> Heya gang
[14:51] <geser> Hi bddebian and congratulations for becoming a FTP master
[14:51] <bddebian> Heh, hi geser, thanks
[14:54] <Laney> oh, argh, forgot that the new cdbs isn't in
[14:54]  * Laney hides in shame
[14:54] <james_w> Laney/directhex: process-removals is suggesting we remove monodoc, should we?
[14:55] <directhex> james_w, source package? yes
[14:55] <james_w> "ROM; Merged into other source by upstream"
[14:55] <Laney> yes
[14:55] <james_w> just source?
[14:55] <directhex> the binaries should be provided by mono and mono-tools
[14:56] <directhex> check the binaries you want to remove - version numbers of 2.0 can go, 2.4 should stay
[14:56] <james_w>    monodoc | 2.0-2ubuntu2 |        karmic | source, all
[14:56] <directhex> i think you should only have 2.4's
[14:56] <james_w> no 2.4s
[14:57] <directhex> oh, it's only a metapackage
[14:57] <directhex> kill it
[14:57] <james_w> ah, there's no monodoc package anymore
[14:57] <james_w> don't you need a transitional package?
[14:57] <james_w> I guess not if it's only a metapackage
[14:58] <Laney> nothing should depend on it
[14:58] <james_w> gone anyway
[14:58] <Laney> ^5
[14:58] <james_w> no, I mean for users
[14:58] <directhex> james_w, the deps appear unversioned
[14:59] <directhex> james_w, i.e. the metapackage pulls in the current correct versions
[14:59] <happyaron> have you made a decision on tor package?
[14:59] <directhex> so not worth fussing IMHO
[15:00] <slytherin> happyaron: Did you ever ask anyone to make a decision?
[15:01] <happyaron> slytherin: I just seen some people are discussing about it, but I went sleep before it ends.
[15:02] <slytherin> happyaron: a discussion does not necessarily means a decision was sought. You hould mail on the mailing list if you want a decision to be made.
[15:02] <happyaron> oh
[15:03] <happyaron> slytherin: is ubuntu-motu list okay?
[15:03] <slytherin> yes
[15:04] <happyaron> thanks
[15:05] <slicer> What's the correct marking for a bug when the conclusion is pretty much "Are you serious? I'm not going to fix that." ? .. Invalid?
[15:06] <slytherin> slicer: isn't there a 'wont fix'?
[15:09] <directhex> invalid.
[15:09] <slicer> slytherin: Not that I can see, no..
[15:09] <slicer> slytherin: That would have been ideal though.
[15:09] <slytherin> slicer: which bug is this by the way?
[15:09] <slicer> bug 385923
[15:10] <slytherin> slicer: and why is that bug invalid?
[15:12] <slicer> slytherin: It's not invalid, but if the user, manually, goes to click "Check for updates", I don't really consider it wrong that the program reports that a newer version exists.
[15:12] <slytherin> slicer: and does the program allow the user to actually upgrade?
[15:13] <slicer> slytherin: No, all it does is say "there's a new version available. Click here to go to the website where the tarball is.".
[15:14] <slytherin> hmm then I think it is ok. I thought it was auto upgrade similar to firefox
[15:14] <slicer> slytherin: The application has that, but that's already been disabled :) All that's left now is the response to manual user interaction.
[15:14] <slytherin> that's fine then.
[15:21] <juli__> Hi all! I always use http://sf.net in watch files for SourceForge based products.. but it doesn't work now. Has something changed?
[15:22] <artfwo> juli__, does your problem look like http://paste.ubuntu.com/250008/ ?
[15:24] <juli__> artfwo, no.  like this: -- In debian/watch, processing watchfile line:  http://sf.net/ini4j/ ini4j-(.+)-all\.zip debian  debian/orig-tar.sh / uscan warning: In debian/watch, / no matching hrefs for watch line
[15:25] <juli__> artfwo, but several days ago everything was ok
[15:25] <dholbach> nhandler: if you could do me a favour, could you please sticky the UDW announce on karmic, packaging and community café?
[15:25] <juli__> it looks like there is no such zip files at all..
[15:26] <artfwo> juli__, I am getting "no matching hrefs for watch line" as well
[15:26] <nhandler> dholbach: Did you make a forum post about it already?
[15:26] <dholbach> nhandler: yep
[15:26] <dholbach> just a few secs ago
[15:26] <Laney> slicer, directhex: There is wontfix for those in bug control
[15:26] <nhandler> dholbach: Do you have a link to the forum post?
[15:26] <directhex> in lp?
[15:26] <dholbach> just un seconde
[15:26] <dholbach> just une seconde
[15:26] <Laney> yes sir
[15:27] <Laney> you should be in it from your motu powers
[15:27] <dholbach> http://ubuntuforums.org/showthread.php?t=1242611
[15:27] <dholbach> http://ubuntuforums.org/showthread.php?t=1242613
[15:27] <dholbach> http://ubuntuforums.org/showthread.php?t=1242612
[15:27] <Laney> oh, that's quite soon
[15:27]  * Laney should prepare
[15:28] <Laney> dholbach: good looking brochure!
[15:28] <nhandler> dholbach: Did you have a post in the karmic forum?
[15:28] <dholbach> Laney: the design folks who did the layout are absolutely fantastic
[15:28] <dholbach> nhandler: one of them should be
[15:28] <dholbach> Laney: it took them a day what I couldn't achieve in a couple of weeks :)
[15:29] <juli__> artfwo, I have the same for http://sf.net/scantailor/scantailor-(.*)\.tar\.gz
[15:29] <Laney> I'm terrible at that kind of thing
[15:29] <dholbach> Laney: same here - I was quite happy with I did before, but it looks very old compared to their brushed up version :)(
[15:29] <artfwo> I think there is a problem with uscan's sourceforge backend then
[15:29] <slytherin> juli__: When you use a line that I believe it goes through some SF redirector on Debian side. May be the redirector is giving problem.
[15:30] <Laney> Adobe InDesign though... tsk tsk
[15:30] <dholbach> oh well :)
[15:30] <artfwo> the redirector looks okay, judging by the output of uscan --debug
[15:31] <nhandler> dholbach: Fridge post is up (I'll make the last changes in a little bit). Forum posts are getting stickied now
[15:31]  * dholbach hugs nhandler
[15:31] <dholbach> thanks so much!
[15:32] <artfwo> by the way, my package (scantailor) binaries have just disappeared from the NEW queue? but they didn't show up in the repositories yet - how long does it take after they pass the queue?
[15:32] <Laney> nhandler: how can I get the forums to say I'm a member/developer?
[15:33] <juli__> artfwo, very strange:(
[15:34] <geser> artfwo: they should get published on the next publisher run (once hourly)
[15:34] <juli__> artfwo, do you have any working watch file.. to check with?
[15:35] <directhex> Laney, use pdfmod to hax the metadata into something more pleasing!
[15:35] <artfwo> juli__, 3 packages from sourceforge are all broken
[15:35] <artfwo> geser, thanks
[15:35] <artfwo> I think a bug needs to be filed against uscan
[15:35] <Laney> GNU/Linux FreeGraphicsEditor RMS edition
[15:35] <directhex> Laney, I believe the abbreviated form is "emacs"
[15:35] <slytherin> artfwo: no, you don't need to file a bug
[15:36] <slytherin> artfwo: as I said it is probably the redirector on debian side that is giving problem.
[15:36] <slytherin> juli__: Did you check cobertura rejection mail?
[15:36] <juli__> slytherin, thanks.. so we should wait
[15:37] <slytherin> when are usually the builds with depwait status are retried?
[15:38] <juli__> sladen, that is why I cares about sf.net:) I corrected a package. Now it uses w3c-dtd-xhtml package for the problem files. And I plan to delete them form upstream.
[15:38] <juli__> ups
[15:38] <juli__> sorry, the previous message was for slytherin :)
[15:39] <slytherin> juli__: Ok. Let me know when you have updated package. Or do you also have uploader rights for cobertura?
[15:39] <geser> slytherin: when the package they depwait on is available (no manual interaction is needed)
[15:39] <slytherin> so are there some kind fo triggers which restarts the build?
[15:40] <juli__> slytherin, no I don't. Actually TB haven't contacted me yet, so I think I don't have uploads rights even for nrtbeans
[15:40] <slytherin> Ok
[15:41] <juli__> slytherin, as soon as sf.net is work, I'll check my corrections and let you know. Thanks!
[15:51] <nhandler> Laney: I sent a PM to matthew and he took care of it for me
[15:52] <Laney> alright
[15:54] <richardmd>  ;)
[17:36] <mhall119|work> hi
[17:36] <mhall119|work> I'm making packages for a GDM and USplash theme
[17:36] <mhall119|work> should the package change the default GDM and Usplash to use them?
[17:37] <mhall119|work> also, I have a -desktop package that combined them, some other artwork and apps, if the individual gdm and usplah packages aren't setting themselves to be default, should the -desktop package be doing that?
[17:37] <slytherin> mhall119|work: no
[17:38] <mhall119|work> slytherin: https://launchpad.net/qimo is what I'm packaging for
[17:39] <sladen> mhall119|work: you merely offere a higher dpkg-divert value
[17:39] <mhall119|work> a what?
[17:40] <Laney> aren't they alternatives?
[17:41] <mhall119|work> I don't think so
[17:41] <mhall119|work> GDM has an line in gdm.conf that tells which to use
[17:41] <mhall119|work> usplash might be, I'd have to double check
[17:42] <Laney> usplash is
[17:43] <sladen> yes, update-alternatives, not dpkg-divert
[17:43] <sladen> see /var/lib/dpkg/info/usplash-theme-ubuntu.postinst  (which installs with a priority of 10)
[17:43] <mhall119|work> ok
[17:43] <artfwo> guys, I have filed a sync request for p7zip-rar some time ago, and now it shows in my uploads on launchpad - is it okay? I have not made any debdiffs or touch the package in any other way
[17:44] <mhall119|work> so  I should install with a higher priority than 10
[17:44] <Laney> artfwo: what did you expect to happen?
[17:44] <sladen> yes, I think kubuntu/xubuntu use 20;  so use 30
[17:45] <mhall119|work> ok
[17:45] <artfwo> Laney, well I didn't expect I shall be the uploader
[17:45] <mhall119|work> how about for GDM?
[17:46] <Laney> artfwo: you made the contribution, its your credit :)
[17:46] <artfwo> hmm, okay
[17:46] <slytherin> mhall119|work: why do you want to make it default?
[17:46] <sladen> mhall119|work: not sure;  the best thing to do is to hunt out a similar theme package and look at it's source!
[17:46] <sladen> artfwo: and in this day-and-age you gotten know *who* to blame ;-)
[17:47] <mhall119|work> slytherin: it's a kids-distro, and the GDM theme has a face browser
[17:47] <artfwo> :)
[17:47] <mhall119|work> I figured it would make it more kid-friendly to have it after install, rather than having to go to Admin panels to set it
[17:49] <mhall119|work> ah, okay, looks like maybe GDM used alternatives too
[17:50] <mhall119|work> but does the login-window configuration dialog change alternatives?  It doesn't seem to
[18:18] <arnd-arndnet> Hi, is there an irc channel related to ubuntu backports?
[18:21] <mhall119|work> arnd-arndnet: #ubuntu-backports?
[18:22] <arnd-arndnet> but this channel is empty, or is this expected?
[18:22] <mhall119|work> ah, you must have just created it
[18:22] <mhall119|work>  /msg alis help  <- to search for channels
[18:23] <hggdh> you can try #ubuntu-quality, or #ubuntu-testing
[18:24] <arnd-arndnet> thx
[18:58] <bddebian> Anyone know who Rafael Proenca / cypherbios is?
[18:59] <ximion> bddebian: https://launchpad.net/~cypherbios
[19:00] <fabrice_sp> bddebian, the maintainer of aptoncd. Why?
[19:01] <slytherin> fabrice_sp: Going forward, can you please subscribe me to all the sync bugs related to maven?
[19:02] <fabrice_sp> slytherin, yes, sure. I was going to send an email to ttx, because I found a package that require a sync, that hasbeen modified by him
[19:03] <fabrice_sp> you can see all the required packages in my ppa (still trying to be able to build maven-plugin-tools, but I'm near)
[19:04] <bddebian> fabrice_sp: I'm trying to figure out if he is going to upload aptoncd to Debian any time "soon" (Since it's been over a year already).  We are going to remove libnautilus-burn soonish
[19:09] <fabrice_sp> bddebian, I'm helping him with the packaging, and there is a version in the ppa, but I don't know about uploading to debian. I can send him an email, if you want
[19:10] <bddebian> fabrice_sp: Please do.
[19:11] <fabrice_sp> slytherin, for the moment, I have 19 packages to sync from debian, and one to merge (and maybe another one, depending on the repsonse of ttx)
[19:12] <slytherin> fabrice_sp: which package is that?
[19:12] <fabrice_sp> classworlds
[19:12] <slytherin> let me take a look
[19:12] <fabrice_sp> slytherin, ttx deleted a dependency, but the latest version in debian added 2 more
[19:12] <fabrice_sp> ok
[19:14] <fabrice_sp> slytherin, my concern is that ttx speaks about a MIR for classworlds, so adding more dependency is not welcome
[19:17] <slytherin> fabrice_sp: right, as per my discussion with ttx. We should only try to get maven stack in. Modifying other libraries to work with maven (installing pom etc) is for karmic + 1
[19:35] <fabrice_sp> slytherin, so that mean that we need to change all the packages from debian to get rid of pom etc? Or the actual packages will stay as is (with the FTBFS)
[19:36] <fabrice_sp> if they stay as-is, I'll stop playing with my ppa, to try to build maven-plugin-tools
[19:37] <slytherin> fabrice_sp: What I meant is that the libraries outside of maven stack should not be modified.
[19:37] <slytherin> fabrice_sp: ludovic is trying to integrate maven with debhelper so that the projects that use maven can build them against the system libraries
[19:38] <fabrice_sp> slytherin, could you please have a look at my ppa (https://launchpad.net/~fabricesp/+archive/testbuild) 16 of the 20 libs are non maven, AFAIK
[19:38] <fabrice_sp> just to know what I should do
[19:39] <slytherin> let me take a look
[19:39] <fabrice_sp> thanks :-)
[19:40] <fabrice_sp> (except plexus-sec-dispatcher, all the other ubuntu1 version are not right)
[19:40] <fabrice_sp> slytherin, ^
[19:42] <slytherin> fabrice_sp: following libraries are not related to maven - commons*, google*, neckohtml, netbeans. I am not sure about wagon.
[19:43] <fabrice_sp> slytherin, wagon seems to be linked: "tools to manage Maven artifacts and deployment "
[19:43] <slytherin> then it is
[19:44] <fabrice_sp> slytherin, I already opened sync request for some of them (google, at least, so should I give you the bug numbers, so that you unsubscribe motu?
[19:45] <slytherin> sure
[19:45] <fabrice_sp> bug #412848
[19:46] <fabrice_sp> actually, it's the only one
[19:47] <fabrice_sp> I was trying to get it built before requesting the syncs
[19:49] <fabrice_sp> slytherin, so my next question is what am I suppose to do next? I have some dependency scheme of packages so should I request the sync for the ones  linked to maven ? Ofr freeze myself?
[19:55] <slytherin> fabrice_sp: go ahead and request syncs for packages related to maven
[20:02] <fabrice_sp> slytherin, ok. I'll subscribe you to them, then. And when a required package cannot be synced, what is the fix? (like libgoogle, for example)
[20:03] <slytherin> nothing, leave the package as it is in Ubuntu.
[20:03] <slytherin> or does other stack depends on google*
[20:04] <fabrice_sp> I'll check, but that mean that we won't be able to fix all the FTBFS in maven  package
[20:05] <fabrice_sp> slytherin, other packages depends on libgoogle ( libdoxia-java and  eucalyptus-javadeps)
[20:06] <fabrice_sp> so we can't sync it
[20:07] <slytherin> better drop me and ttx a mail
[20:07] <slytherin> got to go now.
[20:09] <fabrice_sp> ok. Thanks slytherin
[20:12] <fabrice_sp> bddebian, Rafael is not active any more, so he won't upload the package to debian. I'll submit a diff to Ubuntu, but can't do it for debian
[20:12] <fabrice_sp> this is what the actual developer of aptoncd told me
[20:26] <rugby471> hi guys
[20:26] <rugby471> just a quick question
[20:26] <rugby471> the package f-spot
[20:26] <rugby471> what patching system does it use?
[20:27] <rugby471> what-patch gives me quilt
[20:27] <rugby471> however all the patch files contain @DPATCH@ and all the usual dpatch headers
[20:33] <geser> check the build-depends
[20:38] <gilir> could someone add me to the REVU reviewer team and ubuntu-universe-sponsors team please ? :)
[20:42] <bddebian> fabrice_sp: I can just grab it from Ubuntu or if you want to maintain it officially stick it on mentors.debian.net and I can sponsor for you if you want.
[20:43] <pochu> is it just me (or my dns) or half of the internet is down?
[20:43] <pochu> even http://www.downforeveryoneorjustme.com/ is down for me :)
[20:44] <therm> its there for me
[20:47] <fabrice_sp> bddebian, the only problem is that as it's maintained in launchpad, there is no 'orig tarball. So I've written a get-orig-source. I'll upload it to debian, as soon as I understand how it works :-)
[20:50] <c_korn> hm, games usually depend on /usr/lib/libGL.so . can I add some dependecy to ensure that it exists ?
[20:51] <sebner> c_korn: might be in libgl1-mesa-glx
[20:53] <geser> isn't depending on libgl1 enough?
[20:53] <c_korn> sebner: so can I safely make it depend on libgl1-mesa-glx ? or can this cause conflicts because my libGL comes from the nvidia drivers actually
[20:54] <superm1> shouldn't that be figured out automatically though by shlib deps for your binary?
[20:54] <geser> c_korn: does the nvidia package provide libgl1?
[20:55] <c_korn> I don't use the package but the installer from nvidia.com
[20:55] <sebner> c_korn: I have both packages installed so I don't think there is a problem
[20:55]  * sebner uses the driver from the archive
[20:58] <c_korn> somehow it got not figured out by shlib deps. I got this error: loading libGL.so: QGL_Init: Can't load libGL.so from /etc/ld.so.conf: libGL.so: cannot open shared object file: No such file or directory
[21:11] <gilligan_> hi
[21:12] <gilligan_> does anyone here have some insight into networkmanager ? I'm trying to to diagnose some problem with a GSM usb-stick where networkmanager is stuck in Stage 4 (IPV4 config) and never gets to Stage 5 (IPV4 config commit) -- same hardware works fine with Jaunty
[21:22] <fabrice_sp> Hi. Where can I find some resources that explains the differences between Debian and Ubuntu in term of packaging (that is: what should I do to an ubuntu package to upload it to debian?)
[21:24] <sebner> fabrice_sp: basically it's 1) changelog 2) menu file , other than that just patches which are written for ubuntu
[21:25] <dtchen> anyone mind uploading http://kernel.ubuntu.com/~dtchen/upload_queue/ please?
[21:25] <fabrice_sp> sebner, and to take over an existing package? lintian is speaking about nmu, but I'm trying to upgrade a package, so I'm not sure NMU applies
[21:25] <fabrice_sp> and I should upload source and binary?
[21:25] <sebner> fabrice_sp: doesn't apply.
[21:26] <sebner> fabrice_sp: where?
[21:26] <fabrice_sp> to mentors.debian.net
[21:26] <jbernard__> would someone mind taking a look at a package on REVU? (http://revu.ubuntuwire.com/p/lua-iconv)
[21:27] <sebner> fabrice_sp: AFAIK, uploading is the same as uploading to revu. just use dput
[21:28] <fabrice_sp> sebner, ohh. in their FAQ, the example is done with the file ending with i386.changes, so I thought it was binary upload
[21:28] <james_w> dtchen: sure
[21:28] <fabrice_sp> I'll upload the source then. Thanks!
[21:29] <sebner> you're welcome :)
[21:30] <dtchen> james_w: many thanks. it's build-tested, of course (i'm using it for work)
[21:30] <fabrice_sp> bddebian, uploaded (http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package=aptoncd) I'm sure I will have to fix things :-)
[21:34] <james_w> jbernard__: looks pretty good (though a watch file would be nice), but are you sure you don't want to get it in to Debian first?
[21:34] <james_w> you are targetting Debian in the changelog and closing a Debian ITP
[21:39] <yvan300> hello motu guys :)
[21:39] <jbernard__> james_w: ive already uploaded it to debian, its in NEW right now
[21:40] <james_w> aha
[21:40] <jbernard__> but i wanted to try and get it into karmic before the freeze
[21:40] <james_w> that's fine
[21:40] <james_w> you need to target karmic though
[21:40] <jbernard__> good call
[21:40] <james_w> and make it a -0ubuntu1 version, instead of -1
[21:40] <jbernard__> what about the LP reference?
[21:40] <jbernard__> aha
[21:40] <james_w> nah, that's ok
[21:40] <james_w> unless there is a bug filed
[21:40] <jbernard__> there was
[21:41] <james_w> you can reference it then
[21:41] <jbernard__> ok, perfect
[21:41] <yvan300> you guys should really make the wiki a bit more straightforward
[21:41] <jbernard__> james_w: ill make those changes and re-upload
[21:41] <jbernard__> james_w: thanks!
[21:41] <dtchen> yvan300: sure, what do you take issue with specifically?
[21:42] <yvan300> dtchen, most of it actually, i am trying to catch along but it is so difficult, if you guys could make it a bit easier then more noobs would be able to learn the motu traid :D
[21:43] <bddebian> fabrice_sp: I have to head home, I'll try to hit it up when I get there
[21:43] <james_w> "you should really eradicate world poverty"
[21:43] <james_w> every one agrees, we just need to know where to start
[21:43] <fabrice_sp> bddebian, thanks!
[21:46] <dtchen> james_w: thanks again
[21:46] <james_w> np
[21:47] <james_w> jbernard__: I now see your email address and feel a bit stupid :-)
[21:49] <jbernard__> james_w: no worries ;)
[21:50] <jbernard__> james_w: does the "-0ubuntu1" allow the debian package to easily override once it's in the archive? or could it be "-1ubuntu1"?
[21:50] <james_w> it should be -0ubuntu1, which will mean the tools that compare archives will see it as lower
[21:51] <james_w> and so it will show up as something to merge
[21:51] <jbernard__> ok, thats what I suspected, makes total sense
[21:51] <james_w> the "ubuntu" stops it being automatically overridden, so it would need a "sync" requested when appropriate
[21:51] <james_w> dead easy to do though, so you can just ask in here when needed
[21:55] <jbernard__> got it
[21:55] <jbernard__> ive make the upload, so the pulse should pick it up shortly
[21:55] <jbernard__> s/make/made
[22:01] <james_w> can someone do a second review of http://revu.ubuntuwire.com/p/lua-iconv please?
[22:04] <jbernard__> doh, forgot -sa, no orig tarball got uploaded
[22:04] <jbernard__> should be fixed on the next pulse
[22:05] <james_w> thanks
[22:05] <james_w> I grabbed the old one anyway
[22:06] <jbernard__> ok, all looks good now
[22:09] <james_w> jbernard__: you have my advocation. Strictly we need a second to upload, though I'm tempted to bypass that in this case
[22:09] <james_w> it will only take a couple of minutes for someone else to review though
[22:11] <jbernard__> sounds good, thanks!
[22:32] <iulian> james_w, jbernard__: I've just reviewed it and found nothing to complain about.  Do you want me do upload it?
[22:32] <iulian> s/do/to/
[22:47] <jbernard__> iulian: i vote yes ;) but im not sure if it's up to me
[23:02] <iulian> jbernard__, james_w: lua-iconv has just been uploaded.
[23:02]  * iulian heads to bed.
[23:02] <iulian> Good night.
[23:57] <porthose> would a kind MOTU please ACK bug #415102 :)


[00:17] <SamB_irssi> jelmer: oh ... that doesn't seem to have helped. even with sbronson@ in the https:// url, it still finds "sbronson" as the user to authenticate as ...
[00:23] <SamB_irssi> jelmer: also, apparantly subversion always defaults username to the user's account name?
[00:23] <SamB_irssi> maybe you should allow multiple authentication attempts ...
[00:48] <thunderbolt> I'm having a bit of difficulty doing a bzr get through sftp. I have a repository at example at come and use this command: bzr get<EMAIL_ADDRESS>But I'm getting a EOF during negotiation error.
[00:48] <thunderbolt> I'm on windows and have installed paramiko and pycrypto.
[00:50] <thunderbolt> Would it be a bad idea just to download the repo from example.com using sftp? Could I still merge between them in that case?
[00:57] <mwhudson> hmm
[00:58] <thunderbolt> Hmm?
[01:01] <kingos> lifeless: you there?
[01:02]  * lifeless checks
[01:02] <lifeless> yup, I seem to be
[01:04] <kingos> lifeless: hi. Anything else you wanted me to do about that bzr check failing stuff?
[01:04] <lifeless> oh uhm, what bug number was it
[01:05] <kingos> 356028
[01:05] <lifeless> bug 356028
[01:07] <lifeless> kingos: no, sorry I had lost it from my queue; I've assigned it to me
[01:12] <kingos> lifeless: thanks.
[03:37] <mlh_> thunderbolt: example.com - really?
[03:37] <thunderbolt> Yes. ;-)
[03:37] <mlh_> test taht you can just do plain sftp
[03:37] <mlh_> your own private example.com?
[03:38] <thunderbolt> Thanks mlh_, I can plain sftp to it.
[03:38] <thunderbolt> Yeah, it's actually a domain for my work, it's been changed to example.com to protect the guilty :)
[03:39] <mlh_> me <-- not bzr expert but
[03:39] <mlh_> you can rsync I believe or scp -pr it all and have it work
[03:39] <thunderbolt> Cool!
[03:39] <thunderbolt> Thanks mlh_.
[03:40] <thunderbolt> Now the only problem is pushing it back, I guess I could make a patch/bundle.
[03:40]  * thunderbolt was using bzr for deployment of some django onto a website.
[03:40] <mlh_> perhaps try bzr+svn scheme instead of sftp
[03:41] <mlh_> bzr+svn ?!?!?
[03:41] <thunderbolt> bzr+svn? Do you mean bzr+sftp? I tried that with similar results :(
[03:41] <mlh_> I mean bzr+ssh
[03:41] <thunderbolt> Ah.
[03:41] <thunderbolt> right.
[03:42]  * thunderbolt had no luck with that, either :(
[03:42] <jfroy> jelmer: I just got the weirdest error. I tried to branch a foreign Subversion branch on machine A (which doesn't have the branch). bzr errored out telling me the branch had no revision. Yet I pushed to that branch on machine B not one minute ago >.>
[03:42] <mlh_> Oh dear.  I'll have to pass to 2nd level support then :-)
[03:43]  * thunderbolt chuckles
[03:43] <mlh_> using <your VCS here> for deployment is widely frowned upon
[03:43] <mlh_> but everybody (including me) still does it
[03:44] <thunderbolt> It is?
[03:44] <thunderbolt> Why is it frowned upon?
[03:44] <mlh_> I think you should have a make/scons/maven/... target dir then rsync that target dir to the deployed area
[03:44] <mlh_> because things like .bzr don't belong on  a website
[03:45] <mlh_> there's a chance of inadvertantly exposing too much info
[03:45] <thunderbolt> mlh_: Ah, in my setup .bzr lives in a directory that isn't web accessable.
[03:46] <mlh_> so you think :-)
[03:46] <thunderbolt> It's along with all my Django config stuff (including database passwords)
[03:46] <thunderbolt> So if .bzr is accessable, so is my database, so I'm screwed.
[04:13] <lifeless> there is also a 'bzr upload' plugin
[04:13] <lifeless> mlh_: ^ thunderbolt ^
[04:14] <lifeless> which is expressly for web deployment
[04:14] <thunderbolt> lifeless: Ah, cool!
[04:14] <thunderbolt> Neat, kinda like rsync.
[04:23] <sidnei> seems like my checkout got stuck :(
[04:24]  * sidnei tries once more
[04:25] <lifeless> jam: hi
[04:25] <jam> hi lifeless
[04:25] <jam> just made it into San Jose
[04:25] <jam> I figured I might try to ping rockstar
[04:28] <rockstar> jam, hi.
[04:28] <rockstar> jam, are you in the hotel?
[04:28] <jam> hey rockstar, how and where did you want to meet up tomorrow?
[04:28] <jam> rockstar: yeah
[04:29] <rockstar> jam, um, shall we meet down in the breakfast area for breakfast tomorrow, say, 9ish?
[04:29] <jam> sounds good
[04:29] <rockstar> jam, I'll probably want you to review my notes for the BoF tomorrow night.
[04:30] <jam> certainly
[04:32] <lifeless> jam: I'm analysing the index insertion issue
[04:32] <jam> lifeless: you may want to check out lp:~jameinel/bzr/btree_with_bloom
[04:32] <jam> (just pushed up after I got off the plane)
[04:32] <jam> I haven't done any benchmarking, etc.
[04:32] <lifeless> jam: thanks; I have one here :)
[04:33] <lifeless> jam: I'll be letting you do the tuning I suspect. I just wanted to put some math around it.
[04:36] <jam> lifeless: so I think branching *from* a repo with 500k nodes isn't terrible, because we make large requests (50k roots, 200k internal, 200k leaf)
[04:36] <jam> and that code sorts the request, etc
[04:37] <jam> the issue I was seeing was that *insert* was doing it one at a time
[04:39] <lifeless> yes
[04:39] <lifeless> its NlogN disk reads
[04:40] <lifeless> which is better than N^2 but not that much
[04:40] <lifeless> its superlinear and as its read-and-parse operations per key, it sucks
[04:42] <lifeless> e.g.
[04:43] <lifeless> 95% of time is 1.54M queries (this test data has some duplicates)
[04:43] <lifeless> 3% of time is 1.49M insertions
[04:43] <lifeless> 1.38% is the final read-and-serialise to the finished index.
[04:51] <lifeless> jam: one thing I observed was that bloom probing rehashed
[04:51] <lifeless> jam: we need to have a __contains__ that allows passing in the md5
[04:51] <jam> lifeless: we *can*, but I might point you to BloomMurmur
[04:51] <jam> which is about 5-10x faster
[04:52] <lifeless> I'll leave that in your hands
[04:52] <lifeless> my mail will be finished in < 10 minutes I think
[04:52] <jam> so in my testing
[04:53] <jam> ''.join() was 160ms
[04:53] <jam> str in BloomMurmur
[04:53] <jam> was 500ms
[04:53] <jam> for ~ 100k keys
[04:53] <jam> sorry 24k*20 = 500k keys
[04:54] <jam> I was going to look at allowing tuples, so we don't have to do a string join
[04:54] <jam> anyway, at that point, I wasn't sure if it was specifically worthwhile to cache
[04:54] <jam> versus the complexity
[04:55] <SamB_irssi> jam: but you could just put them in a dict!
[04:55]  * SamB_irssi teases
[04:55] <jam> SamB_irssi: :)
[04:55] <lifeless> SamB_irssi: we're talking about the implementation of a dict on disk :)
[04:55] <jam> right, the whole point here is to use a lightweight memory object that lets us drop the actual keys, etc to disk
[04:56] <SamB_irssi> (yeah, my "suggestion" *was* intended as utter point-defeating  nonsense ;-)
[04:58] <jam> rockstar: I was looking over the schedule, and it seems the first sessions start at 8:30, do you want to meet up a bit earlier?
[04:59]  * rockstar looks at the schedule again.
[04:59] <rockstar> jam, oh dear.  Yea, how 'bout 730 or so?
[04:59] <jam> rockstar: sure
[04:59] <jam> http://www.mysqlconf.com/mysql2009/public/schedule/grid
[04:59] <jam> btw
[05:00] <jam> ah, I was reading Monday it looks like 8:30 is keynotes
[05:00] <jam> but still good to go to
[05:00] <rockstar> jam, yea, I have that bookmarked.  For some reason, my brain skipped the keynotes.
[05:02] <rockstar> jam, maybe we ought to skip out on some talks and go visit this: http://www.mysqlconf.com/mysql2009/public/schedule/detail/7791
[05:03] <jam> rockstar: yeah, I think we will
[05:03] <rockstar> jam, it seems to kinda go all day long.
[05:03] <jam> yep
[05:03] <rockstar> "a community organized event designed to share and improve the essential skills required to participate in collaborative, free and open online projects"
[05:06] <SamB_irssi> "bug reporting", "grepping", and "patching"?
[05:06] <lifeless> jam: mail sent
[05:15] <mwhudson> Peng_: fwiw, i like the idea of a single LoggerheadConfig object being created in serve-branches and being passed around the various wsgi app instances
[05:16] <mwhudson> (and i still haven't reviewed your branches properly)
[05:16] <Peng_> mwhudson: Okay, cool. :)
[05:16] <lifeless> mwhudson: is my search fix landed?
[05:16] <mwhudson> lifeless: yes, i think so
[05:16] <lifeless> good
[05:16] <lifeless> now, to get it working on bzr-playground.gnome.org
[05:16] <lifeless> also, that needs to start pulling git :(
[05:24] <BasicOSX> What options do I need to pass to bzr init to test the latest branch format? And will LP support it?
[05:24] <lifeless> BasicOSX: do you mean the development6-rich-root format?
[05:24] <BasicOSX> lifeless:  yes
[05:24] <BasicOSX> --development6-rich-root
[05:24] <BasicOSX> is what I thought
[05:24] <lifeless> -format=development6-rich-root
[05:24] <lifeless> lp won't support it
[05:25] <lifeless> and its a one-way migration, stuff you commit in there can't be moved to regular formats
[05:25] <Peng_> LP won't support it? Why not?
[05:25] <lifeless> Peng_: lp is running 1.13
[05:25] <BasicOSX> won't support it "now" is probably what he means :-)
[05:25] <lifeless> right
[05:25] <Peng_> Oh. I misunderstood.
[05:27] <lifeless> :)
[05:27] <BasicOSX> Peng:  it's ok, I spent the whole day being misunderstood. Endless debate over Free (speech) and free (beer) and the GPLv1, GPLv2, and GPLV3
[05:27] <lifeless> BasicOSX: at a conference?
[05:27] <lifeless> and zomg gpl1?!?!?!
[05:28] <BasicOSX> lifeless:  /blush in my  WoW guild :-P related to Curse/WoWI blocking WoWMatrix from  downloading Addon source code
[05:28] <lifeless> heh
[05:28] <lifeless> curse are very odd
[05:29] <BasicOSX> waaay of topic here, but 3 of the addons I use are GPL and I stated that the GPL requires, if request, access to the source code
[05:29] <lifeless> BasicOSX: #ubuntu-wow :P
[05:30] <BasicOSX> to anyone, and those addons are only on curse, so in effect they are not compliant with with the GPL then religion kicked in and everything go ugly :-)
[05:30] <lifeless> heh
[05:30] <BasicOSX> endless rounds of emacs vs vi
[05:30] <BasicOSX> windows vs linux
[05:31] <BasicOSX> GPL vs BSD
[05:31] <lifeless> so they don't have to allow anyone without the binary access, but blocking by client is arguably a violation yes
[05:31] <BasicOSX> open source vs Free software vs commercial software
[06:19] <Kamping_Kaiser> s/commercial/proprietary
[06:23] <Peng_> Cue endless debate over *that*. :D
[06:54] <Kamping_Kaiser> not really, commercial just means 'for money' :)
[07:01] <jamesh> lifeless: if they distribute binaries without source, they need to provide source access to anyone on request.
[07:01] <jamesh> if everyone who had access to the binaries also had access to the source at the same time, then they could deny requests from third parties
[07:04] <jamesh> they wouldn't be required to support any particular method of source distribution, as long as they use "a medium customarily used for software interchange"
[07:39] <lifeless> jamesh: its more subtle than that
[07:40] <lifeless> jamesh: and not very interesting
[08:10] <robin_dewd> I don't know when it started, but I have some branches that when I commit changes to them locally, they automatically want to commit to the remote (bzr+ssh) repository and this causes some delay for me when committing that I would rather not at times
[08:10] <robin_dewd> how do I turn that off? ;-)
[08:10] <bob2> bzr unbind
[08:11] <robin_dewd> thanks
[08:22] <jelmer> jfroy: hi
[08:22] <jelmer> jfroy: this seems similar to the problem you were reporting earlier
[08:40] <jfroy> jelmer: hey
[08:41] <jfroy> I filed a bug to report it
[09:16] <jfroy> jelmer: Ah I see, yes the 2 bugs may be duplicates.
[09:16] <jfroy> Didn't catch my eye at fist because the exception and error message are different.
[09:46] <Lambo_> hi folks
[09:48] <Lambo_> is it possible to create a PHP comment block on top of a PHP file via Bazaar, with the whoami name + last commit?
[09:49] <Mez> we seem to be having regular issues where we get "too many concurrent connections" - it's gotten to a point where one branch is unusable.
[09:50] <Mez> is there any reason that this could happen on a regular basis
[09:50] <bob2> Lambo_: bzr has nothing like cvs's $Id$, if that's what you're talking about
[09:51] <Lambo_> bob2, i just want bzr to insert the last commit in each file
[09:51] <bob2> Lambo_: nope
[09:59] <Mez> this just doesnt seem to work. and it's getting extremely frustrating
[10:04] <bob2> to lp?
[10:04] <lifeless> Mez: didn't we debug this last week?
[10:04] <lifeless> bob2: we have filters now that can do $id$ if people want
[10:06] <Mez> lifeless: yes, we were, and we've just worked out the issue.
[10:06] <Mez> Zen's "magic filtering"
[10:06] <teknico> hi guys, stumbled into #354036 again
[10:07] <teknico> I added the traceback to the ticket
[10:07] <Mez> which doesn't like us using SSH, and kills the connection if we send across a certain control char
[10:07] <lifeless> Mez: !!!
[10:07] <Mez> lifeless: after changing the route on the box, it worked straight away
[10:10] <Mez> lifeless: such a horrid issue :(
[10:10] <lifeless> Mez: might be worth a faq entry on answers.launchpad.net/bzr for this
[10:11] <Mez> lifeless: really? I think it's just our setup to be honest
[10:11] <lifeless> Mez: well, up to you. Be nice if someone else runs into it to have an easy answer ;)
[10:11] <lifeless> anyhow, ciao, /wave everyone
[10:12] <Mez> "change ISP" isn't a valid answer
[11:01] <asabil> hi all
[11:01] <asabil> is it normal that bzr locks when using bzr send with gmail ?
[11:30] <poolie> asabil: did someone answer?
[11:32] <Peng_> poolie: Nope.
[11:32] <Peng_> You didn't miss anything.
[11:44] <poolie> asabil: no, it's not normal
[11:44] <poolie> what happens if you hit Ctrl-C?
[11:52] <asabil> poolie: nothing happens when I hit ctrl-C
[11:52] <poolie> it's still hung?
[11:53] <asabil> but later I get a error: (110, 'Connection timed out')
[11:53] <poolie> like this? https://bugs.launchpad.net/bugs/364462
[11:53] <asabil> the smtp server address seems correct to me: smtp.gmail.com
[11:55] <asabil> poolie: well it is the same issue, but unrelated to the bzr-email plugin
[11:55] <asabil> which I don't have installed
[11:55] <poolie> right
[11:55] <poolie> i've just commented that i think it's actually a core issue
[11:58] <asabil> thanks
[12:21] <poolie> asabil, i'd guess there was just some transient outage on your network causing it to be unreachable
[12:21] <poolie> or indeed it's not impossible there was a glitch at google
[12:21] <poolie> unless it's reproducible
[12:22] <asabil> poolie: to me it seems like gmail only accepts smtp over ssl
[13:30] <VSpike> Am I completely misunderstanding what bzr missing does?  I run it between two branches where one is massively ahead of another, and it says "Branches are up to date."
[13:30] <awilkins> Anyone going to the Jaunty release party in London?
[13:31] <VSpike> I'd expect it to show me committed revisions that are present in one branch but not the other
[13:32] <awilkins> Arse, that's Thursday
[13:39] <lifeless> VSpike: it should list both sides; are you running bzr mising other-url?
[13:39] <poolie> VSpike:  that is what it's supposed to do
[13:40] <lifeless> hi poolie
[13:40] <lifeless> gnight all
[13:40] <poolie> hi lifeless
[13:40] <VSpike> Ah. Perhaps I see the problem. Both branches were bound to the same parent, but one had not had bzr update run
[13:40] <VSpike> So bzr st showed a very old revisions
[13:41] <VSpike> but doing the bzr missing seemed to do a bzr update at the same time, which sort of makes sense.
[13:51] <SamB> VSpike: I don't see how that makes sense
[13:51] <SamB> are you trying to call bzr missing with two arguments?
[13:51]  * SamB doesn't have any idea what that would do
[13:52] <VSpike> Nope.. I mean I was trying to compare two branches, so I cd'd into one and did "bzr st", then "bzr missing <Other>".  It said they were up to dat.e
[13:53] <VSpike> So I cd'd into other and did "bzr log | head" and "bzr missing <First>" and it said up to date - yet the head revisions were totally different
[13:53] <VSpike> sorry, in the above replace "bzr st" with "bzr log | head"
[13:54] <VSpike> But when I cd'd back into <First>, and did "bzr log | head" again, it showed the same head.  And bzr info revealed they were both checkouts of the same branch, a third one.
[13:55] <bialix> jelmer: ping
[13:57] <SamB> VSpike: ah. checkouts! right.
[13:57] <SamB> I forgot about heavyweight checkouts. I ran into some strange mergy issues with them ...
[13:57] <SamB> ... and haven't used 'em since
[14:00] <VSpike> I started using them because I'm terrible at remembering to commit, let alone push :)
[14:00] <SamB> ah
[14:01] <SamB> well, I'm more interested in not losing changes to unintended "merge"s
[14:01] <SamB> maybe I should instead figure out how to reproduce the issue and report it ...
[14:18] <SamB> jelmer: shouldn't the subvertpy docs be online ?
[14:20] <SamB> jelmer: also, the "epydoc" target doesn't seem to work right in an unbuilt subvertpy source tree
[14:20] <huf> hi. how do i set the parent branch?
[14:21] <SamB> you can use pull --remember
[14:21] <SamB> or you could edit the .bzr/branch/branch.conf file
[14:22] <huf> can i use some short-names for other remote branches?
[14:22] <LarstiQ> huf: with the bookmark plugin, bm:<name>
[14:22] <LarstiQ> huf: next to the builtin :parent, :public, :submit etc
[14:22] <SamB> LarstiQ: and where do you get it ?
[14:23] <huf> where can i find docs on those builtins?
[14:23] <huf> and what each is for, and when each is chosen as a default
[14:23] <LarstiQ> SamB: without look at http://bazaar-vcs.org/BzrPlugins I'd guess lp:bzr-bookmark
[14:23] <poolie> jam, hi?
[14:27] <huf> cool, i think i got it
[14:27] <huf> thanks
[14:29] <SamB> LarstiQ: I don't suppose you can bookmark just a URL prefix?
[14:29] <luks> you can
[14:29] <luks> then you can use bm:foo/path/to/branch
[14:29] <SamB> neato
[14:29] <luks> where foo is e.g bzr+ssh://example.com/path/to/repo
[14:30] <SamB> or it could be svn+https://dosemu.svn.sourceforge.net/svnroot/dosemu, no?
[14:30] <luks> yes
[14:31] <SamB> of course, I still haven't gotten authentication to work for me ...
[14:31] <huf> what happened to the bzr versions? what came after 1.5?
[14:31] <SamB> presumably 1.6?
[14:32] <huf> oh, 14... i cant read.
[14:32] <SamB> then .7, .8, .9, .10 ...
[14:32] <huf> yes yes, i see now
[14:33]  * SamB wishes the NFS at his school's cs department was faster ...
[14:35]  * SamB wonders why SVN doesn't check out files in alphabetical order
[14:38] <awilkins> SamB: It does it in inode order
[14:38] <awilkins> (SVN FS inode, not normal-world fs inode)
[14:38] <SamB> awilkins: but the inodes don't exist yet
[14:38] <SamB> oh
[14:38] <SamB> some kind of progress indicator would be nice ...
[15:00] <jelmer> SamB: yeah, the docs could be online, it's just too much effort to keep them up to date
[15:03] <SamB> jelmer: buildbot? cron job?
[15:09] <jelmer> SamB: No python on the machine that my homepage is on
[15:10] <jelmer> SamB: It also seems like it's not too much effort for whoever is going to use subvertpy to build it
[15:13] <Peng_> I dunno. I find building docs to be easy, but copying and pasting the URL into Firefox a pain. :D
[15:46] <LarstiQ> SamB: I relatively frequently do things like `bzr missing :parent/../foo`
[15:47] <Peng_> Hey, that works?
[15:47] <Peng_> I totally didn't know that.
[17:16] <SamB_irssi> jelmer: well, maybe you should at least debianize the docs ?
[17:17] <SamB_irssi> because I don't currently build subvertpy myself on my own machine, and the one at school lacks all the doc-building tools ...
[17:17] <SamB_irssi> (I also don't think I have room for the build-deps on my personal machine)
[17:17] <jelmer> SamB_irssi: any chance you can file a wishlist bug?
[17:17] <SamB_irssi> ah, sure
[17:18]  * SamB_irssi wonders if there is something wrong with Debian's subversion ...
[17:20] <jelmer> SamB_irssi: why is that?
[17:20] <SamB_irssi> jelmer: is there an up-to-date ppa for subvertpy?
[17:20] <jelmer> SamB_irssi: no
[17:21] <SamB_irssi> jelmer: oh, well, it doesn't seem to cache my auth credentials for that repository I've been having so much trouble with ...
[17:21] <jelmer> SamB_irssi: svn itself (not bzr involved) ?
[17:21] <SamB_irssi> even with the options explicitly set
[17:21] <SamB_irssi> yes, SVN
[17:21] <SamB_irssi> though I admit I haven't actually done a commit
[17:21] <SamB_irssi> just revision property manipulations
[17:22] <jelmer> do you perhaps have subversion configured to not store password /
[17:22] <jelmer> s?
[17:23] <SamB_irssi> jelmer: not entirely, but I'm trying not to!
[17:23] <SamB_irssi> and I can't see how to make subversion mumble aloud what it's doing ...
[17:24] <LarstiQ> SamB: strace? ;)
[17:25] <SamB_irssi> LarstiQ: strace doesn't tell me what configuration settings subversion has determined ...
[17:25] <SamB_irssi> or what it's basing it's decisions on ...
[17:26] <SamB_irssi> jelmer: oh, I guess you want me to file a debian bug huh ...
[17:27] <jelmer> SamB_irssi: yeah
[17:27] <SamB_irssi> almost filed it in launchpad ;-)
[18:06] <SamB_irssi> jelmer: oh, did you catch that I still haven't managed to commit to sf.net via bzr-svn?
[18:14]  * Kinnison yays as his answer to problem 67 on projecteuler.net is correct
[18:34] <jfroy> jelmer: any thoughts on the branch problem? It
[18:34] <jfroy> *It's kind of a bummer not being able to get that branch out of svn, especially since it started as a bzr branch :p
[18:53] <ricardokirkner> hi. I want to use bzr for our project, but due to internal policies, we have to keep all our code inside a svn repo. In order to cope with that, I thought of using a post-commit hook, that would just push the changes to the svn repo. In that way, every time someone commits to our bzr main branch, it gets pushed to the central svn repo
[18:54] <ricardokirkner> how can I do this? (what is the best way to achieve this?)
[18:54] <ricardokirkner> from my research I see I can write hooks for branches, but not for the whole repo...  (i am using a shared repo)
[18:54] <pygi> ricardokirkner, is it just you who wants to use bzr?
[18:54] <ricardokirkner> do I have to write a hook for each branch in the repo, or is there a way to make this easier?
[18:55] <ricardokirkner> pygi, no.. its a team of people
[18:55] <ricardokirkner> otherwise I would just use bzr-svn
[18:55] <ricardokirkner> I want to use bzr.. just push to svn as a side-effect
[18:56] <pygi> hmmm
[18:57] <SamB_irssi> jelmer: I've noticed a message about refusing a basic authentication challange now ...
[18:58] <pygi> ricardokirkner, you can set global hook for a user
[18:58] <pygi> would that work?
[19:00] <ricardokirkner> mhhh
[19:01] <fullermd> You could just use a bzr central branch, and cron pushing it to svn Every So Often(tm)...
[19:01] <ricardokirkner> I dont think so, as that would require that every team member commits with the same user
[19:01] <fullermd> If everybody's going to actually use bzr, that could work....
[19:01] <ricardokirkner> fullermd, that might work...
[19:01] <ricardokirkner> it's not 'clean' ,. but it might work
[19:01] <ricardokirkner> thx
[19:02]  * fullermd specializes in 'not clean'   8-}
[19:02] <ricardokirkner> :-)
[19:10] <phinze> how difficult would it be to implement a "poor man's PQM" with a pre-commit hook on a shared branch?
[19:11] <rockstar> phinze, are you using Launchpad?
[19:12] <phinze> no i'm in a dev group at a university
[19:12] <phinze> trying to see if there's a way to get PQM-like functionality without significantly changing the workflow of the developers
[19:13] <rockstar> phinze, well, I guess it wouldn't be too hard.  Tarmac is more lightweight than PQM, but is (currently) specific to Launchpad.
[19:13] <phinze> ahh that's why you ask
[19:13] <rockstar> Tarmac doesn't use a hook though.
[19:13] <LarstiQ> ricardokirkner: does the policy state how soon the code must be in the svn repo?
[19:13] <phinze> rockstar: you think it would be better to look into modifying tarmac?
[19:13]  * phinze knows nothing about tarmac
[19:13] <rockstar> phinze, bzr branch lp:tarmac
[19:15] <rockstar> phinze, it's undergone some big changes since 0.1, but I don't see a direct way currently to have it be non-launchpad specific.  If you do, I'd be glad to review and merge it.
[19:15] <LarstiQ> phinze: james_w has recently worked on a poor man's PQM
[19:17] <phinze> LarstiQ: thanks, james_w: ping?
[19:19] <phinze> rockstar: cool, rooting around in it now... so it's based off the Launchpad concept of " Branch Merge Proposals"?
[19:19] <rockstar> phinze, yes.
[19:20] <rockstar> phinze, actually, the best way to do a poor man's PQM with Tarmac would probably be to create a new TarmacScript
[19:21] <phinze> yeah that makes sense
[19:22] <phinze> okay here's a dumber question about hooks
[19:22] <phinze> given a pre-commit hook in a BzrBranch... is there a way of failing the commit?
[19:24]  * LarstiQ would assume raising an exception
[19:24] <phinze> or is the hook only allowed to spin off side effects and not get in the way
[19:25]  * LarstiQ looks at the docs
[19:25]  * phinze is looking as well, and not finding...
[19:25] <james_w> phinze: http://paste.ubuntu.com/155496/
[19:26] <phinze> james_w: you come in and answer all the questions! :)
[19:26] <phinze> raise errors.TipChangeRejected("The testsuite failed")
[19:27] <james_w> phinze: it can raise any exception
[19:27] <LarstiQ> phinze: hmm, mention of this should be more clear in `bzr help hooks`
[19:27] <james_w> that one says "I didn't go wrong, I want to cleanly stop the operation please", which means bzr formats it differently
[19:28] <james_w> it's specific to the tip_change hooks though
[19:28] <james_w> I don't think it works for pre_commit
[19:28] <phinze> gotchya
[19:28] <phinze> well tip_change is good enough in our case
[19:28] <phinze> we're using append_revisions_only on the shared branches anyways
[19:29] <LarstiQ> errors.HookFailed
[19:29] <LarstiQ> might still not be entirely correct, given its docstring
[19:30] <phinze> in fact, tip_change is probably more correct
[19:32] <phinze> well this definitely gives me some stuff to play with... rockstar, LarstiQ, james_w: thanks
[19:32] <james_w> phinze: if it suits you we could turn the above in a project and work to make it useful to more people
[19:33] <james_w> it was a quick hack the other day after I get fed up of committing broken stuff myself :-)
[19:33] <phinze> haha that's exactly what brings me here with the interest
[19:33] <phinze> i would definitely be interested in that
[19:33]  * phinze is still in the process of making the snippet work ATM
[19:33] <james_w> my snippet?
[19:34] <phinze> yeah, just shuffling some branches around here
[19:34] <james_w> install it as ~/.bazaar/plugins/testrunner.py
[19:35] <james_w> then edit ~/.bazaar/locations.conf to ahve
[19:35] <james_w> [/path/to/branch]
[19:35] <phinze> ... hmm so it needs to be installed under the user's home dir who will be doing the tip change?
[19:35] <james_w> pre_change_branch_tip_test_command = ./run-tests
[19:35] <phinze> any way to install it system-wide...?
[19:36] <LarstiQ> phinze: sure, bzrlib/plugins
[19:36] <phinze> this will be going on a shared server to protect a branch shared by many users using bzr+ssh
[19:36] <james_w> you can set it to a parent directory, and the same command will be run for all users under that directory
[19:36] <phinze> cool
[19:36] <james_w> phinze: "bzr version | grep bzrlib"
[19:36] <james_w> and install it in the plugins/ directory there
[19:36] <james_w> you will need to tweak it to use branch.conf as well in that case
[19:36] <james_w> otherwise each user would have to edit their locations.cond
[19:36] <phinze> gotchya
[19:41] <phinze> command = config._get_best_value("pre_change_branch_tip_test_command") # ...ok?
[19:42] <phinze> james_w: ^^
[19:44] <james_w> phinze: I think so
[20:42] <james_w> phinze: how's it working for you?
[20:43] <phinze> james_w: working great!
[20:43] <james_w> cool
[20:51] <phinze> hmm ok
[20:51] <phinze> james_w: bzr: ERROR: Received bad protocol version marker: '(in /tmp/tmpzMKiVL/export)\n-
[20:51] <phinze> i get that when running this over bzr+ssh
[20:51] <james_w> urgh
[20:51] <phinze> any idea what that means?
[20:51] <james_w> it's presumably redirecing stdout or stderr back to the client
[20:51] <kirkland> is there some configuration place that I can set my default signature to be appended on bzr commits?
[20:52] <james_w> hey kirkland
[20:52] <james_w> you mean line email signature>
[20:52] <james_w> ?
[20:52] <kirkland> eg, Signed-off-by: Dustin Kirkland<EMAIL_ADDRESS>[20:52] <james_w> not currently
[20:52] <kirkland> james_w: yeah, perhaps
[20:52] <james_w> oh
[20:52] <james_w> no there is
[20:52] <kirkland> james_w: sweet, pray tell
[20:52] <james_w> you need to write a few lines of python though
[20:53] <kirkland> james_w: i'm okay with that
[20:53] <kirkland> james_w: though that would be a nice thing to set in .bazaar/bazaar.conf
[20:54] <kirkland> james_w: commit_signoff = Foo
[20:54] <james_w> from bzrlib import msgeditor
[20:54] <james_w> def add_signoff(commit, start_message):
[20:55] <james_w>     branch = commit.branch
[20:56] <james_w>     config = branch.get_config()
[20:56] <phinze> james_w: sounds like i just need to give subprocess.call the correct pipes for output
[20:56] <phinze> i'm guessing bzrlib.trace might have them...?
[20:57] <james_w>     message = config._get_best_value("commit_signoff")
[20:57] <james_w> if message is None:
[20:57] <james_w> err, scratch that last line
[20:57] <james_w>     if message is None:
[20:57] <phinze> james_w: actually it was command = config._get_user_option("pre_change_branch_tip_test_command")
[20:57] <james_w>         return start_message
[20:57] <phinze> er whoops
[20:57] <phinze> wrong case :(...
[20:57]  * phinze steps back a minute
[20:57] <james_w>     return start_message + "\n\n%s\n" % (str(message),)
[20:57] <james_w> kirkland: if you can piece that together :-)
[20:58] <james_w> I can stick it in a pastebin if you like
[20:58] <james_w> save it as "~/.bazaar/plugins/commit_signoff.py"
[20:58] <james_w> oh, you'll need a start_message is None check before appending to it as well
[20:59] <james_w> phinze: what do you mean by "correct pipes"?
[20:59] <kirkland> james_w: neat, thanks
[21:00] <kirkland> james_w: pastebin would be cool
[21:00] <phinze> idk wondering if subprocess.call by default is looking to the wrong place for stdout and stderr when it's being run over bzr+ssh
[21:03] <james_w> kirkland: http://paste.ubuntu.com/155535/
[21:03] <james_w> kirkland: even with the call to actually register the hook :-)
[21:03] <james_w> you should be able to set commit_signoff either globally, or per-location
[21:04] <james_w> I don't think it does entirely what you want, but it
[21:04] <james_w> 's the best you can do from a plugin right now I think
[21:04] <james_w> phinze: I'm not sure there is a correct place for them
[21:04] <phinze> james_w: lemme try None
[21:05] <james_w> I don't know if it's possible, but you would really want to send this information back to the client somehow
[21:05] <phinze> indeed
[21:05] <james_w> fg
[21:07] <phinze> hmm that didn't help
[21:07] <phinze> received bad protocol version marker...
[21:07] <james_w> None is the default
[21:08] <james_w> you can use subprocess.PIPE to redirect
[21:08] <phinze> perhaps need to prefix bzr+ssh:// to the tmp thing
[21:15] <kirkland> james_w: cool, were does this plugin go?
[21:15] <kirkland> james_w: .bazaar/plugins/*
[21:16] <james_w> that'll work
[21:16] <kirkland> james_w: does it need to be in a subdir of that?
[21:16] <kirkland> james_w: named anything special?  __init.py__ or some such?
[21:16] <james_w>  "~/.bazaar/plugins/commit_signoff.py" will be fine
[21:21] <kirkland> james_w: The MessageEditorHooks hook 'commit_signoff' is unknown in this version of bzrlib.
[21:21] <kirkland> Unable to load plugin 'commit_signoff' from '/home/kirkland/.bazaar/plugins'
[21:21] <kirkland> james_w: do i need to register it?
[21:21] <james_w> kirkland: sorry
[21:21] <james_w> "commit_message_template"
[21:21] <james_w> change the first arg to install_named_hook to that
[21:22] <kirkland> k
[21:22] <kirkland> aborting commit write group: AttributeError("'LocationConfig' object has no attribute 'commit_signoff'",)
[21:22] <kirkland> bzr: ERROR: exceptions.AttributeError: 'LocationConfig' object has no attribute 'commit_signoff'
[21:23] <kirkland> [DEFAULT]
[21:23] <kirkland> email = Dustin Kirkland<EMAIL_ADDRESS>[21:23] <kirkland> launchpad_username = kirkland
[21:23] <kirkland> commit_signoff = Signed-off-by: Dustin Kirkland<EMAIL_ADDRESS>[21:23] <kirkland> that's in my bazaar.conf
[21:23] <james_w> phinze> command = config._get_best_value("pre_change_branch_tip_test_command") # ...ok?
[21:23] <james_w> phinze: ^ was that correct?
[21:24] <phinze> james_w: no --> command = config._get_user_option("pre_change_branch_tip_test_command")
[21:24] <phinze> that did
[21:24] <james_w> kirkland: try changing "_get_best_value" to "_get_user_option"
[21:25] <james_w> thanks phinze
[21:25] <kirkland> james_w: bingo
[21:25] <kirkland> james_w: you da man
[21:25]  * kirkland owes james_w a beer
[21:25]  * phinze does as well
[21:25] <james_w> kirkland: not that it won't work with "-m"
[21:25] <james_w> ^note
[21:25] <kirkland> james_w: tis okay
[21:26] <kirkland> james_w: this get's me much closer
[21:26] <james_w> it modifies what the editor shows to you, so if you never see the editor then it won't do anything
[21:26] <kirkland> james_w: i was using vim bindings
[21:26] <kirkland> james_w: but this is much nicer
[21:26] <james_w> cool
[21:26] <jelmer> SamB_irssi: how do you mean?
[21:54] <SamB_irssi> jelmer: with svn from unstable, I get this error:
[21:54] <SamB_irssi> naesten@hydrogen:~/hacking/dosemu% bzr push svn+https://dosemu.svn.sourceforge.net/svnroot/dosemu/branches/debugger/
[21:54] <SamB_irssi> bzr: ERROR: Permission denied: ".": MKACTIVITY of '/svnroot/dosemu/!svn/act/5d67fa37-fa8b-4227-a397-f31dd0b8dee7': authorization failed: Could not authenticate to server: rejected Basic challenge (https://dosemu.svn.sourceforge.net)
[21:54] <jelmer> SamB_irssi: does it work with "plain" svn?
[21:55] <SamB_irssi> is there some?
[21:55] <jelmer> SamB_irssi: I mean, does it work without using bzr but only svn
[21:55] <SamB_irssi> it let me edit revision properties
[21:56] <SamB_irssi> without rejecting any basic authentication
[21:56] <jelmer> does it let you do commits?
[21:58] <SamB_irssi> hmm ...
[22:00] <jelmer> SamB_irssi: ah, that's svn+https:// that's not prompting
[22:01] <SamB_irssi> jelmer: hmm?
[22:01] <SamB_irssi> and yes, I can commit
[22:01] <jelmer> SamB_irssi: https:// works fine
[22:02] <SamB_irssi> jelmer: wasn't the svn+ your idea?
[22:03] <jelmer> SamB_irssi: well, it does work as a workaround to bzr triggering the smart server
[22:03] <SamB_irssi> I mean ... didn't you suggest I use that for this ... ?
[22:04] <SamB_irssi> oh well.
[22:05] <SamB_irssi> now I'm getting something about a failing is_canonical assertion ...
[22:05] <jelmer> SamB_irssi: one sec
[22:06] <jelmer> SamB_irssi: I've pushed a fix for the svn+https:// auth issue
[22:06] <jelmer> SamB_irssi: not sure about the is_canonical one issue, are you running the latest subvertpy?
[22:07] <SamB_irssi> jelmer: where would I get the .deb for that?
[22:08] <jelmer> SamB_irssi: In Debian (sid)
[22:11] <SamB_irssi> jelmer: well, last I checked, it was the latest that I'd seen in apt ...
[22:11] <jelmer> SamB_irssi: ah, sorry
[22:12] <jelmer> SamB_irssi: in that case, please run inside of gdb and pastebin the backtrace
[22:12] <jelmer> SamB_irssi: sorry this is a bit of a bumpy road..
[22:13]  * SamB_irssi hopes he won't need a -dbg package -- those things are getting kind of big lately
[22:13] <jelmer> SamB_irssi: You might need the libsvn-dbg one actually, for a sensible backtrace :-/
[22:14] <SamB_irssi> well, I'll try without first
[22:14] <SamB_irssi> the svn+ fix does seem to help, though
[22:15] <jelmer> cool
[22:15] <SamB_irssi> jelmer: what did you want to see?
[22:16] <jelmer> SamB_irssi: the output of the 'bt' command inside of gdb
[22:16] <SamB_irssi> well, yeah, I was getting ahead of myself
[22:17] <SamB_irssi> http://paste.ubuntu.com/155563/ is what I get so far
[22:17] <SamB_irssi> which function would you like to know something about the arguments of?
[22:20] <jelmer> basically which subvertpy function is triggering the crash
[22:21] <SamB_irssi> oh
[22:21]  * LarstiQ votes for ra.Auth()!
[22:21] <LarstiQ> jelmer: but I saw you fixed that, thanks :)
[22:22]  * SamB_irssi mumbles something about there not being a libsvn-dbg package ?
[22:23] <jelmer> SamB_irssi: libsvn1-dbgsym
[22:23] <jelmer> LarstiQ: np :-) I think that's not actually used by bzr-svn though
[22:24] <LarstiQ> jelmer: it was step1 in trying to figure out why password_encoding=subversion didn't work
[22:24] <jelmer> LarstiQ: oh, ok
[22:24] <SamB_irssi> jelmer: well ... I don't see that either
[22:25] <SamB_irssi> what repository are you getting it from ?
[22:25] <jelmer> SamB_irssi: it's in the debug repository
[22:25] <jelmer> deb http://debug.debian.net/debian unstable/debug main
[22:25] <LarstiQ> jelmer: credentials would raise StopIteration and I had no clue why
[22:25] <jelmer> LarstiQ: because it didn't have any credentials cached ? (-:
[22:26] <LarstiQ> jelmer: bollocks!
[22:26] <LarstiQ> jelmer: it does, and it works for svn
[22:26] <LarstiQ> but I'll figure it out later
[22:26] <LarstiQ> sleep now
[22:28] <SamB_irssi> jelmer: unfortunately I don't seem to be able to get that version of libsvn1
[22:28] <jelmer> SamB_irssi: :-/
[22:29] <jelmer> SamB_irssi: another thing that may help is using a subvertpy built with debugging symbols
[22:29] <jelmer> LarstiQ: this is with the latest bzr-svn?
[22:29] <SamB_irssi> jelmer: if you were to upload such a python-subvertpy-dbg to experimental, I'd be happy to try it
[22:30] <jelmer> SamB_irssi: I can't, subvertpy is in sid and adding a new binary package would mean another 3 or 4 weeks for it to go through NEW
[22:30] <SamB_irssi> jelmer: oh :-(
[22:30] <SamB_irssi> well, to anywhere, really
[22:31] <jelmer> SamB_irssi: Is there any chance you can just try with a manually built subvertpy?
[22:31] <SamB_irssi> (experimental messes up sid?)
[22:31] <jelmer> SamB_irssi: all binary packages from one source package end up in the same distribution, not multiple
[22:31] <jelmer> SamB_irssi: there shouldn't be a need to install subvertpy to try this
[22:31] <jelmer> just set PYTHONPATH appropriately
[22:32] <SamB_irssi> yes but I'd need the svn headers :-(
[22:32] <jelmer> yeah
[22:33] <SKArfaceGC> is there any documentation on cvsps-import other than the README file?
[22:33] <SamB_irssi> which seems to need 35 megs ... in /usr ...
[22:33] <SamB_irssi> I might have them ...
[22:33] <jelmer> SamB_irssi: You should be able to remove it again once you've run this
[22:34]  * SamB_irssi doesn't get why subversion's headers require the installation of so many others -- Suggests:, sure, but Requires: ?
[22:35] <jelmer> SamB_irssi: they include the others
[22:35] <SamB_irssi> all of them?
[22:35] <jelmer> samb_irssi: indirectly, but yes
[22:35] <SamB_irssi> it still seems pretty sick ...
[22:35] <jelmer> directly it only depends on libapr-dev and libapr-util-dev IIRC
[22:36] <jelmer> apr depends on a lot I think
[22:37] <SamB_irssi> I mean, seriously -- why are the headers for 3 different DBMS-type things needed?
[22:37] <SamB_irssi> (BDB, mysql, and sqlite)
[22:38] <SamB_irssi> jelmer: okay, how do I build subvertpy with debug flags ? I haven't done that sort of thing in a while ...
[22:38] <jelmer> SamB_irssi: ./setup.py build_ext -i -g
[22:40] <SamB_irssi> and how would you suggest I bzr-svn to use this one?
[22:40] <SamB_irssi> +get
[22:40] <jelmer> export PYTHONPATH=/path/to/subvertpy
[22:40] <SamB_irssi> (there sure were a lot of deprecation warnings...)
[22:42] <jelmer> yeah, that's correct, we'd like to stay compatible with old verisons
[22:43] <SamB_irssi> it would be better if they cited a version since which they were deprecated ...
[22:43] <jelmer> SamB_irssi: that's not possible in C afaik
[22:45] <SamB_irssi> jelmer: ... since when are deprecation warnings even possible ?
[22:45] <SamB_irssi> (in C)
[22:45] <jelmer> SamB_irssi: gcc extensions
[22:45] <SamB_irssi> oh
[22:50]  * SamB_irssi gets it to actually load on his 3rd try ...
[22:51] <SamB_irssi> (1st time I added it to the end of PYTHONPATH, second try I used ~ in a place it wasn't expanded ...)
[22:52]  * SamB_irssi is tired of waiting for "finding fileprop revids" or whatever ...
[22:53] <SamB_irssi> jelmer: great. now it has to go and work on me!
[22:53] <jelmer> SamB_irssi: ok, so looks like it's probably a bug fixed in the current subvertpy
[23:06] <SamB_irssi> jelmer: what do you mean about "experimental" uploads delaying movement from unstable to testing ?
[23:07] <jelmer> SamB_irssi: ? That's not what I said
[23:07] <SamB_irssi> oh. maybe you missed where I said "experimental" and not unstable?
[23:08] <jelmer> SamB_irssi: no, I never said experimental uploads delay movements from unstable
[23:08] <jelmer> SamB_irssi: it's just not possible to upload a source package from which the binary packages are in different distributions
[23:08] <jelmer> the source package's distribution determines where the binary packages go
[23:09] <SamB_irssi> well, I mean, you could upload the whole thing to experimental, couldn't you ?
[23:09] <jelmer> so the source package subvertpy would have the binary packages python-subvertpy and python-subvertpy-dbg
[23:09] <jelmer> SamB_irssi: yes, but why would I upload to experimental? subvertpy lives happily in sid
[23:10] <SamB_irssi> hmm, well, I dunno ;-)
[23:10] <SamB_irssi> I'm not a DD
[23:11] <SamB_irssi> right now, I'm just thinking it would be nice to have a subvertpy which actually allows me to push the way I just did in some Debian repository would be nice
[23:11] <jelmer> SamB_irssi: I don't see why that would have to be with a experimental rather than an unstable package though
[23:12] <jelmer> SamB_irssi: The problem is I don't have time to upload either at the moment
[23:12] <SamB_irssi> ah
[23:12]  * SamB_irssi mumbles something like "why do they have to make these things take time?"
[23:13] <jelmer> I should have time for it in about a weeks time, when I get back home
[23:14] <SamB_irssi> oh, that's a nice and short moment I guess ;-)
[23:15] <SamB_irssi> oh, how would you merge a subversion branch back into the trunk with bzr-svn ?
[23:15] <SamB_irssi> (supposing that there were no changes on trunk)
[23:16] <jelmer> SamB_irssi: bzr pull
[23:16] <jelmer> (as you would with a regular bzr branch)
[23:17] <SamB_irssi> does that need to be in an actual checkout, or is it fine if it's just a branch with all the same commits ... ?
[23:18] <jelmer> SamB_irssi: not sure if I follow..
[23:18] <SamB_irssi> it's okay if I pull into something that isn't actually a bzr checkout of the SVN trunk, yes?
[23:19] <jelmer> yeah
[23:27] <SamB_irssi> okay ... actually there were some changes on trunk(!) but it seems okay ...
[23:30] <SamB_irssi> hmm. svn annotate still leaves something to be desired :-(
[23:31] <SamB_irssi> (all the changes are attributed to the merge: see http://dosemu.svn.sourceforge.net/viewvc/dosemu/trunk/src/arch/linux/debugger/mhpdbgc.c?annotate=1888, notice that all my changes are marked 1888)
[23:32] <phinze> dev-noob question: how to get bzr to print out full errors rather than just the "friendly" and terse bzr: ERROR: Received bad protocol version marker: '(in /tmp/tmppPHYeP/export)\n-'
[23:32] <SamB_irssi> jelmer: but you can't do anything about that :-)
[23:32] <phinze> i know python has a backtrace for me somewhere in there
[23:32] <phinze> i could pdb i suppose
[23:34] <SamB_irssi> BZR_PDB=on bzr foo ...
[23:34] <phinze> aha
[23:34] <SamB_irssi> (if you want to pdb, that is)
[23:35] <phinze> SamB_irssi: perfect; thanks
[23:35] <bob2> phinze: full tracebacks are in ~/.bzr.log, too
[23:37] <phinze> bob2: mmm also helpful
[23:38]  * phinze is trying to debug a hook that runs tests and rejects commits... works locally but when run through bzr+ssh gets raise errors.UnexpectedProtocolVersionMarker(in_buf)
[23:38] <Peng_> You can also see the full tracebacks with -Derror, right?
[23:44] <lifeless> phinze: interesting
[23:45] <lifeless> phinze: where is that raised from?
[23:45] <phinze> lifeless: subprocess.call of an external command... looks like the output of that command is getting into in_buf... which expects something
[23:45] <phinze> oop may have just fixed it
[23:45] <lifeless> phinze: subprocess by default using stdin and stdout
[23:46] <phinze>  subprocess.call(command, cwd=export_dir, shell=True, **stdout=subprocess.PIPE**)
[23:46] <lifeless> so you may have been sending your output back over the wire to the client
[23:46] <lifeless> yup
[23:46] <phinze> happy days are here again
[23:46] <phinze> :)
[23:55] <lifeless> phinze: you may want stderr=subprocess.STDOUT
[23:55] <phinze> lifeless: yeah i'm poking around with that, but for some reason i get 0 output from the subprocess command on my terminal when i specify it
[23:56] <lifeless> phinze: thats correct, your plugin will get it all
[23:56] <lifeless> phinze: imagine that you are committing over bzr+http
[23:57] <lifeless> in that situation stderr and stdout are effectively /dev/null *unless* you capture them via subprocess with stdout=PIPE and stderr *either* PIPE or STDOUT
[23:57] <phinze> riight ok
[23:57] <lifeless> now, we don't have a way at the moment for you to send an output stream during the commit process
[23:58] <lifeless> because its a hook happening at the end of a push
[23:58] <phinze> hmm okay so to a relative python dunce... is there a way for me to get that output displayed to the user?
[23:58] <phinze> (which in this case is the output from a testsuite running..?)
[23:59] <lifeless> phinze: not at the moment - think of it like a cronn job running on the server
[23:59] <phinze> with just stdout=subprocess.PIPE i get about half the output on my terminal when running push
[23:59] <lifeless> if it fails, you can raise an exception with any data you want
[23:59] <lifeless> the exception is stringified and passed back over the wire
[23:59] <lifeless> if it succeeds, no output is shown