[00:13] <Turl> hi
[00:14] <mdke> what are the chances of read-only kicking in shortly?
[00:14] <Turl> is launchpad completely off and unreadable on purpouse? I thought it would be still readable
[00:14] <mwhudson> low
[00:14] <mdke> just deciding whether to go to sleep or not
[00:14] <beuno> mdke, none
[00:14] <mwhudson> sadly
[00:14] <Turl> :(
[00:14] <beuno> it didn't work exactly as we wanted (at all)
[00:14] <mdke> ok, sleep it is! Thanks
[00:14] <mdke> good luck with getting it working
[00:15] <beuno> mdke, have a good night
[00:15] <mdke> you too
[00:19] <wgrant> The new rollout process doesn't work, I take it?
[00:21] <cokebottles> holy crap
[00:21] <cokebottles> is this launcpad ?
[00:21] <cokebottles> for the service or whatever ?
[00:21] <matsubara> wgrant: rough edges
[00:21] <cokebottles> hm...
[00:21] <cokebottles> how long LP down for ?
[00:21] <wgrant> cokebottles: See the topic.
[00:21] <matsubara> cocooncrash: Launchpad will be offline from 22:30-23:30 UTC for code updates
[00:21] <EricHerman> I at least find it somewhat encouraging that while the ReadOnly was removed from the notice, the maintenance window was not changed: 22:30-23:30 UTC
[00:22] <cokebottles> ok thanks; also..  how can i get total bytes of a certain trunk?
[00:22] <mwhudson> yeah, it will just be down, there's nothing affecting the rollout of the new code
[00:23] <cokebottles> so when i do a bzr  i know how many bytes gonna trasfee ?
[00:23] <wgrant> Bug #xyz is about displaying the size in the web UI.
[00:23] <wgrant> Calculation of 'xyz' is delayed for 10 minutes.
[00:23] <cokebottles> i'm new to this ?  there's a bug for that issue ?
[00:24] <wgrant> I don't know of another way, unfortunately.
[00:24] <wgrant> There is.
[00:24] <cokebottles> ok
[00:24] <wgrant> Bug #350031, it is.
[00:24] <cokebottles> i'm just starting out; i'm sorry if i'm being dumb
[00:26] <cokebottles> same thing as ubottu
[00:26] <cokebottles> oh well; i was just gonna work on the wubi stuff; i wanted to make my custom stuff
[00:26] <wgrant> cokebottles: That's because Launchpad is down for an upgrade at the moment.
[00:27] <cokebottles> ok; well thanks for the info; sorry again
[00:28]  * wgrant is amused at some Launchpad bugmail from last night: somebody recommending a SAML/OpenID implementation for Launchpad because "it's all php, opensource and dead easy to use."
[00:29] <Snova> Heh.
[00:32] <ajmitch> wgrant: and being in PHP is what matters most
[00:32] <wgrant> ajmitch: Right. PHP is obviously good.
[00:35] <wgrant> It's just unfortunate that Launchpad is written in the inferior Python. I actually heard somebody in one of my classes say that Python was OK, but couldn't do as much as PHP.
[00:35] <beuno> Launchpad's up
[00:36] <wgrant> beuno: Thanks.
[00:36] <beuno> wgrant, hi  :)
[00:37] <wgrant> beuno: Hi!
[00:37] <ajmitch> great, thanks
[00:48] <Turl> is the launchpad librarian up?
[00:49] <Turl> nevermind, it worked now :)
[02:21] <jgoguen> what do I need to look at to fix the rejection error "Could not find person ''" when trying to upload to my PPA
[02:22] <Ampelbein> jgoguen: check your ~/.dput.cf
[02:22] <cody-somerville> jgoguen, What arguments are you providing to dput?
[02:22] <jgoguen> cody-somerville: dput ppa file-roller_2.26.1-0ubuntu2~jgoguen1_source.changes
[02:23] <mwhudson> and maybe check that the email address in the changelog is known to launchpad?
[02:23] <jgoguen> Ampelbein: what should I look for in there?
[02:24] <jgoguen> mwhudson: the email I put in the changelog has been used for other uploads to my PPA, so I assume that means it's recognized by LP?
[02:24] <Ampelbein> jgoguen: incoming = ~<yourLPname>/<yourLPppa>/ubuntu
[02:24] <wgrant> mwhudson: The email address doesn't mean anything until later; this error is related to the FTP upload path.
[02:24] <jgoguen> Ampelbein: I have that, and it's worked for other uploads: incoming = ~jgoguen/ppa/ubuntu/
[02:25] <wgrant> jgoguen: Is that the 'ppa' target?
[02:25] <wgrant> Ubuntu 9.04 has a default 'ppa' target which requires an argument.
[02:26] <wgrant> It sounds to me like you're using that, but not passing the argument it wants.
[02:26] <mwhudson> wgrant: oh ok
[02:26] <wgrant> (which is username/ppaname)
[02:27] <jgoguen> wgrant: ahh now I feel like a true idiot :)  I'd had [ppa] defined in ~/.dput.cf and just clued in that I'd changed it to [jgoguen]
[02:27] <cody-somerville> http://blog.launchpad.net/ppa/simplifying-dputcf-for-multiple-ppas
[02:30] <jgoguen> wgrant: thanks for prodding me with that, now that I'm using the target I'd actually defined it's working great again
[02:31] <wgrant> jgoguen: See cody-somerville's blog post - you don't need to define your own target any more.
[02:31] <bjsnider> what is a "build score"?
[02:31] <wgrant> bjsnider: There's a bug filed to document that better. It's basically the build priority.
[02:32] <cody-somerville> bjsnider, an integer that is used to determine which builds should be dispatched to the builders first
[02:32] <jgoguen> wgrant: will do, that looks like it'll make my life a lot easier...thanks again!
[02:32] <wgrant> jgoguen: np
[02:32] <bjsnider> how is the build score determined?
[02:32] <wgrant> That's complicated.
[02:33] <wgrant> IIRC, different initial priorities are assigned depending on the pocket, component, privacy of the PPA, urgency of the upload (but only slightly). The score increases over time.
[02:33] <wgrant> The score starts at 0 when a build is retried, so only time contributes to retries.
[02:34] <wgrant> Buildd admins occasionally rescore builds if something is particularly urgent.
[02:35] <bjsnider> i wish i could run these things thru on my own system as a dry run before sending them in so i wouldn't have to retry them
[02:35] <wgrant> bjsnider: You should be using pbuilder or sbuild.
[02:35] <bjsnider> i use debuild
[02:35] <bjsnider> does that count?
[02:36] <wgrant> No.
[02:36] <bjsnider> ok
[02:36] <wgrant> pbuilder and sbuild give a very similar environment to the buildds, in that almost no packages are installed in it by default.
[02:36] <wgrant> So it's a good way to test the build dependencies.
[02:37] <bjsnider> well i always try building the stuff manually so everything works before i send it in
[02:37] <bjsnider> but this last time it didn't work, although it built here.
[02:38] <wgrant> What was the error?
[02:38] <wgrant> And why did you need to retry it?
[02:38] <bjsnider> the linker missed just about all of the kde stuff, egven though kdelibs-dev was installed
[02:39] <bjsnider> wgrant, http://launchpadlibrarian.net/26107443/buildlog_ubuntu-jaunty-i386.kaffeine_0.8.7-1ubuntu6~ppa4_FAILEDTOBUILD.txt.gz
[02:39] <bjsnider> everything's "undefined reference to" even though it was fine here with exactly the same packages
[02:40] <wgrant> bjsnider: Use pbuilder or sbuild to hopefully reproduce it locally.
[02:40] <wgrant> That's much more helpful for debugging.
[02:41] <bjsnider> the lpia build worked, but amd64 and i386 failed. i think the vm was zapped or something. i'm just going to try it again
[02:41] <wgrant> That's unlikely.
[02:42] <bjsnider> yes but there was other evidence of it
[02:43] <bjsnider> how would i use pbuilder to do a dry run?
[02:44] <wgrant> bjsnider: https://wiki.ubuntu.com/PbuilderHowto
[02:57] <xiaohui> Who knows how to reverse the revision to the initial state in launchpad?
[02:58] <xiaohui> I need to revert my branch to beginning state
[02:59] <spiv> xiaohui: "bzr revert -r -1" will revert a local working tree.
[03:00] <xiaohui> spiv, I need the branch in lauchpas to revert to the revision 1 , any method?
[03:00] <spiv> xiaohui: "bzr push --overwrite -r 1 URL" will overwrite the branch at URL to your revision one.
[03:00] <spiv> (Hmm, I meant "1" not "-1" in the revert command too)
[03:01] <xiaohui> oh, thank you,spiv
[05:06] <jimt> I have a project that has code imported from an external subversion URL... but its import status is "Suspended".  How do I request that someone prod it to try again?
[05:06] <jimt> (Or does it happen periodically?)
[05:12] <lifeless> https://answers.launchpad.net/launchpad-code
[05:13] <jimt> Thanks
[05:19] <mwhudson> jimt: which is the branch?
[05:19] <jimt> https://code.launchpad.net/~vcs-imports/exe/trunk
[05:20]  * mwhudson looks
[05:21] <mwhudson> jimt: i hit 'approve', let's see what happens
[05:21] <ripps> Why does one of the builds in my PPA say it's going to take 9 hours before it can build?
[05:21] <jimt> Thanks!
[05:27] <wgrant> ripps: There's a fairly large i386 PPA backlog (as can be seen at https://launchpad.net/builders), probably because most of the buildds are still doing releases.u.c duty.
[05:27] <ripps> wgrant: I've been able to build when there are 300+ builds lined up, but I've never had to wait 9 hours for it to build.
[05:28] <wgrant> ripps: Maybe there are some particularly huge packages (like OpenOffice.org or gcc) queued up.
[05:28] <mwhudson> ripps: maybe there's three copies of openoffice ahead of you in the queue :)
[05:28] <mwhudson> actually that would be more than 9 hours, i think...
[05:29] <ripps> sigh... I might need to find somewhere else test compile this package, my package compiles 20 plugins simultaneously and large builds like this tend to my pc segfault
[05:30] <wgrant> It has been a week. I wonder if releases.u.c load is low enough yet...
[05:31] <ripps> Okay, here's another question, what do lpia builds always seem to be so much faster? Is it easier to compile, or do alot of packages just not build in that archetecture?
[05:33] <wgrant> i386 and lpia are practically identical architectures, but i386 gets all of the architecture independent builds.
[05:33] <wgrant> This means that each build will take about the same amount of time, but i386 will get lots more builds.
[05:34] <wgrant> That's why in Ubuntu we have one more i386 buildd than other archs have (except armel, but armel is a new arch).
[05:35] <ripps> Are there any plans to expand the PPA's from just the 3 archetectures? Ubuntu builds for 8, certainly some people using the other 5 might want to use a PPA?
[05:36] <wgrant> ripps: The three PPA-supported archs are those that Xen supports. Until there is a reliable, fast and secure virtualisation mechanism for an arch, it can't possibly be enabled for PPA usage.
[05:37] <wgrant> There is a preliminary port of Xen to ARM.
[05:37] <wgrant> So that might happen eventually.
[05:37] <ripps> Cool
[05:39] <ripps> I notice that some PPA's build in more the standard 3 archs, does that mean their PPA has permission to use the Ubuntu build servers?
[05:39] <wgrant> Yes.
[06:47] <savvas> what does the "affects me too" actually do? does it notify the developers?
[06:51] <jamesh> savvas: it is designed to stop you from posting "me too" comments
[06:51] <jamesh> I don't think it results in any extra mail
[06:51] <savvas> so it just changes a value?
[06:52] <lifeless> savvas: it bumps a counter, its useful for reporting and determining common bugs
[06:52] <savvas> no "This bug has been marked as me too from *this-many* users"?
[06:52] <jamesh> savvas: you can sort bug listings by "number of users affected"
[06:52] <savvas> ah now I see :)
[06:52] <jamesh> so developers can use it to help determine importance on bugs
[06:53] <savvas> thank you!
[07:07] <wgrant> Does malone or launchpad-answers own the bug->question converter?
[07:07] <wgrant> I suppose I'd be best to file it against malone, as malone has developers...
[07:22] <jml> wgrant: sure.
[07:22] <jml> wgrant: also, when in doubt, just file against launchpad
[07:23] <wgrant> jml: True. Thanks.
[07:24] <jml> np
[07:24] <jml> one of the nice things about the Launchpad bug tracker is that it doesn't *really* matter -- it's pretty easy to reassign.
[07:25] <wgrant> Right.
[07:26] <wgrant> But Answers is probably a bit of a blackhole these days.
[09:45] <rowinggolfer> ok... I have what I consider to be a serious issue
[09:45] <rowinggolfer> I refer to http://launchpad.net/openmolar
[09:45] <rowinggolfer> I have spend 4 months developing an application
[09:45] <rowinggolfer> which I believe is going to be of use to a LOT of people.
[09:45] <LarstiQ> moin rowinggolfer
[09:45] <rowinggolfer> morning.
[09:46] <rowinggolfer> now I am delighted to say people are beginning to contribute
[09:46] <rowinggolfer> and I am very grateful to Bryan Harris in particular who has created packages and put it into a PPA.
[09:47] <rowinggolfer> however, he is now marked as top contributer to the project
[09:47] <rowinggolfer> and frankly, this is unfair.
[09:47] <rowinggolfer> I know it is my fault, because I committed all my code anonymously because bzr didn't know who I am
[09:48] <rowinggolfer> but I have people who want to stop me doing this project
[09:48] <rowinggolfer> and I am risking getting my ass sued by even doing it
[09:48] <LarstiQ> is that why you worked anonymously?
[09:48] <LarstiQ> right
[09:48] <rowinggolfer> no.
[09:48] <rowinggolfer> I didn't work anonymously
[09:48] <rowinggolfer> I simply didn't know to register my launchpad email with BZR
[09:49] <rowinggolfer> all my commits (32 of) came from Neil Wallace <neil@neil.12-inch>
[09:49] <rowinggolfer> this is fixed now...
[09:50] <rowinggolfer> but if my enemies look at the site they may come to the conclusion that I did not write this app.
[09:50] <wgrant> 34 commits is tiny in the long run, is it not? Soon enough your identified commits will vastly outnumber the others.
[09:50] <rowinggolfer> which would imply I have had an external programmer hacking on the database I purchased from them
[09:50] <wgrant> Plus if they want to really see who wrote it, they should look at the commit logs themselves.
[09:50] <rowinggolfer> 34 commits of 40,000 lines of code I've written
[09:50] <wgrant> Launchpad karma isn't meant to be used for anything serious; it takes too little into account.
[09:51] <rowinggolfer> well, I would like to resolve this.
[09:52] <rowinggolfer> anyway... Issue 2.
[09:52] <rowinggolfer> there is now a proposal to "merge" the branches.
[09:52] <rowinggolfer> which seems to make sense.
[09:52] <rowinggolfer> but I do not know how to do it.
[09:53] <bigjools> hello bigkevmcd
[09:53] <wgrant> rowinggolfer: Do you have a merge proposal?
[09:53] <jpds> rowinggolfer: cd into your projects directory and run: bzr merge lp:~brywilharris/openmolar/debianize
[09:54] <rowinggolfer> jpds thanks.
[09:54] <jpds> rowinggolfer: After you've review it, bzr commit and bzr push it as usual and then go to https://code.edge.launchpad.net/~brywilharris/openmolar/debianize/+merge/6036 and mark it as Approved, Rejected, or whichever you want.
[09:56] <jpds> rowinggolfer: https://help.launchpad.net/Code/Review has more information.
[09:57] <rowinggolfer> jpds: thanks. I am totally new to version control etc...
[09:57] <jpds> rowinggolfer: Everyone starts off at one point, no worries :)
[09:58] <rowinggolfer> jpds: I wish I had cut my teeth on a smaller project :(
[09:59] <rowinggolfer> jpds...
[09:59] <rowinggolfer> bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
[09:59] <rowinggolfer> oh... hang on
[09:59] <rowinggolfer> hmmm.
[09:59] <rowinggolfer> what have I done wrong now.
[10:00] <jpds> Are you in your projects working directory and does it have a '.bzr' subdirectory?
[10:01] <rowinggolfer> yes
[10:02] <rowinggolfer> allthough I actually make changes in a different directory, then run this command.
[10:02] <rowinggolfer> alias ompush='rsync -av --exclude="*.pyc" --exclude="*~" --exclude="tmp" --exclude="main.py" --exclude="connect.py" --exclude="print.pdf" --exclude="documentation" /home/neil/openmolar/openmolar/ /home/neil/openMolarBZR/openmolar && cd /home/neil/openMolarBZR/openmolar && bzr add -v && bzr commit && bzr push lp:~rowinggolfer/openmolar/trunk'
[10:03] <wgrant> rowinggolfer: Why don't you work in the bzr branch normally?
[10:03] <rowinggolfer> because I don't understand bzr :(
[10:03] <rowinggolfer> this program is mission critical for my business
[10:04] <wgrant> rowinggolfer: In general you would just develop in the bzr branch as usual, commiting as you go.
[10:04] <rowinggolfer> and the documentation must NOT be public at this point
[10:04] <savvas> http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html
[10:04] <rowinggolfer> also, main.py and connect.py have password information....
[10:04] <wgrant> Just don't add them.
[10:04] <bigjools> keep private stuff in a separate branch
[10:05] <jpds> rowinggolfer: Did you know you can: bzr ignore filename - to have bzr not include them in adds and commits?
[10:05] <savvas> hm..
[10:05] <wgrant> OK, so the problem with merging those branches is that they aren't related at all.
[10:05] <rowinggolfer> test prints have patient information.... if one of those gets pushed... I risk being struck off
[10:05] <wgrant> The debianisation branch is not derived from lp:openmolar
[10:05] <rowinggolfer> ah. ok.
[10:05] <savvas> it seems the branch wasn't created using the main branch
[10:06] <rowinggolfer> jpds... I need to use that bzr ignore.
[10:06] <rowinggolfer> and it needs to be 100% reliable for reasons I mention above.
[10:07] <rowinggolfer> rsync I know and trust.... bzr I do not
[10:07] <wgrant> I don't see how working in the bzr branch could make it less reliable.
[10:07] <savvas> you can use something like: bzr ignore *.pyc
[10:07] <savvas> it will create a file .bzrignore in your branch
[10:07] <rowinggolfer> savvas: I think bzr does that by default
[10:07] <rowinggolfer> ignore *.pyc I mea
[10:07] <savvas> well.. either way, it was an example :)
[10:07] <rowinggolfer> ok.
[10:07] <rowinggolfer> that's a great tip then
[10:08] <savvas> the next time you commit & push, it will include that .bzrignore file
[10:08] <rowinggolfer> really I need to take the password stuff out... and create a settings file
[10:09] <jpds> rowinggolfer: You should be able to do: bzr ignore tmp main.py connect.py documentation
[10:10] <jpds> rowinggolfer: And then check with bzr ignored
[10:10] <rowinggolfer> ok... doing that now.
[10:11] <rowinggolfer> jpds... but a working connect.py IS required...
[10:11] <jpds> Sorry, I assumed you didn't want it because of --exclude="connect.py"
[10:12] <wgrant> rowinggolfer: It's a trivial change to move the auth details to something like settings.py that just contains that, and then ignore that.
[10:12] <rowinggolfer> wgrant: I know.
[10:13] <rowinggolfer> there is some historical issue here related to getting all the opnemolar modules onto the users path.
[10:13] <rowinggolfer> I don't alter the path until they have provided the correct password
[10:14] <rowinggolfer> so what I am pushing up to launchpad is pretty much a demo only version at the moment
[10:15] <rowinggolfer> ok.. I am going to wait for Bryan to wake up (he's in the states) then I am going to try and speak to him.
[10:15] <rowinggolfer> bloody hell collaboration is REALLY hard.
[10:16] <wgrant> rowinggolfer: bzr makes it really easy once you work out how to use it all properly. It does take a bit of getting used to, though.
[10:16] <rowinggolfer> wgrant: and I need to stop being such a control freak, probably.
[10:17] <wgrant> given that it's very difficult to merge from that branch, as it's not much of a branch, you might be best to diff the trees manually and work out what changes there are in Bryan's. In future, contributors should 'bzr branch lp:openmolar', then you can merge trivially.
[10:19] <rowinggolfer> he only changed 2 files.
[10:20] <rowinggolfer> wgrant - I think I need to make myself a development branch ASAP.
[10:20] <wgrant> Make sure you use -N on the diff command.
[10:20] <wgrant> I suspect the debian/ directory is brand new.
[10:20] <wgrant> rowinggolfer: Is lp:openmolar not the dev branch?
[10:20] <rowinggolfer> yes it is.
[10:20] <rowinggolfer> wgrant: yes it is.
[10:21] <rowinggolfer> and it is normal to hack away in that branch?
[10:21] <rowinggolfer> and not have an "experimental" branch etc...
[10:22] <LarstiQ> wgrant: or use bzr in the one branch to produce a diff, and apply that on the other
[10:22] <wgrant> rowinggolfer: It really depends. Some projects (most from Canonical, for example) never make changes directly in the main branch - they create feature or bugfix branches, and merge them in.
[10:22] <rowinggolfer> I am concerned because my little dog-fooding project is now being packaged by others.
[10:22] <wgrant> Others commit directly to trunk, branching only for big things.
[10:22] <wgrant> Or not at all.
[10:22] <wgrant> My primary project branches quite a lot, but some things go straight to trunk at the moment.
[10:23] <rowinggolfer> I think I need to make a "stable" and insist that people package from that?
[10:23] <wgrant> bzr makes branching so nice.
[10:23] <wgrant> Is there any point having a stable yet?
[10:23] <rowinggolfer> lol, probably not
[10:23] <rowinggolfer> it is other people jumping the gun
[10:23] <wgrant> It's always useful to have a package.
[10:23] <rowinggolfer> a dude is packaging it for partis
[10:24] <rowinggolfer> ok... I need to get hacking on it again.
[10:24] <rowinggolfer> l8r folks.
[10:28] <alkisg> Can I download all the commit messages from a branch? In particular, from https://code.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk  ?
[10:29] <wgrant> alkisg: What exactly do you want to do? Is the output of 'bzr log' not sufficient?
[10:29] <alkisg> wgrant: I think that'll do - thanks, trying...
[10:29] <alkisg> (bzr newbie here :))
[10:30] <wgrant> alkisg: You can either do 'bzr log lp:somebranch', or check it out and do 'bzr log' in the branch. The latter is better if you plan to deal with the branch again.
[10:30] <rowinggolfer> wgrant: btw - check out the new logo - https://launchpad.net/openmolar
[10:31] <wgrant> rowinggolfer: Nice!
[10:32] <rowinggolfer> provided by richard querin.
[10:33] <rowinggolfer> question - launchpad does not provide any space for screenshots... correct?
[10:33] <wgrant> Correct.
[10:33] <rowinggolfer> pity.
[10:33] <wgrant> Rather.
[10:33] <wgrant> There has been talk for a while of introducing a wiki, which would fulfill that purpose.
[10:33] <sinelaw> hi! Is there a way to cancel a pending build?
[10:33] <wgrant> But that's a while off, at best.
[10:34] <wgrant> sinelaw: Not without direct database access - why?
[10:34] <sinelaw> i have 2 builds that will fail for sure, after wasting some resources :)
[10:34] <wgrant> Ah. Probably not worth it then, although it would be nice...
[10:35] <wgrant> If you upload a new version, the old builds will never hit the builders.
[10:35] <sinelaw> I did, but i still see the build records
[10:36] <wgrant> They should show up as 'Build for superseded source', but probably not immediately.
[10:36] <wgrant> Maybe only once queue-builder or the buildd master gets to them.
[10:48] <rowinggolfer> wgrant: re the wiki idea..
[10:49] <rowinggolfer> if a project were to have a folder in the main trunk called "launchpad/html" (or suchlike)
[10:49] <rowinggolfer> and launchad saw it
[10:49] <jml> wgrant: I believe the wiki thing is one of the most popular bugs on launchpad.
[10:50] <wgrant> jml: It would have to be.
[10:50] <jml> rowinggolfer: we've actually thought about doing something like that too.
[10:50] <rowinggolfer> and that folder contained only plain html files....
[10:50] <rowinggolfer> I am going to make an html folder...
[10:50] <wgrant> rowinggolfer: Putting it in trunk and allowing arbitrary HTML are both probably bad ideas, but something along that lines would be easy and good.
[10:50] <rowinggolfer> might as well use bzr to manage that
[10:50] <jml> rowinggolfer: it's a good idea, and in some ways easier than a full-blown wiki
[10:50] <wgrant> A separate branch and a restrictive subset of HTML or something like ReST. That would be nice, easy and safe.
[10:51] <rowinggolfer> *.chm
[10:51]  * rowinggolfer ducks
[10:51] <jml> chm!
[10:52] <jml> ahh, the memories :)
[10:52] <wgrant> The bad, bad memories.
[11:32] <danilos> jtv: you are dearly missed by henning on IRC and/or skype :)
[11:32]  * henninge tries to hold back the tears ...
[11:35] <henninge> jtv: there is no point in hiding! ;-)
[12:22] <tansell> so, anyone know where I can find the current delay in having ppa stuff build?
[12:23] <wgrant> tansell: https://launchpad.net/builders will give you the current queue depths.
[12:24] <wgrant> They're rather high at the moment due to the temporary lack of buildds.
[12:25] <tansell> no estimate on how long the queues will take?
[12:25] <bigjools> your own build will have an ETA on its page
[12:25] <tansell> bigjools, I must be blind as I don't see such a thing?
[12:26] <bigjools> tansell: what is your PPA URL?
[12:26] <wgrant> bigjools: Maybe you could show the ETA next to the builds on IArchive:+index.
[12:26] <bigjools> wgrant: nice idea
[12:26] <wgrant> I don't think many people know about the actual build pages.
[12:27] <tansell> https://launchpad.net/~mithro/+archive/ppa
[12:27] <wgrant> And they're pretty boring.
[12:27] <tansell> I tried going to
[12:27] <tansell> https://launchpad.net/~mithro/+archive/ppa/+builds
[12:27] <tansell> but don't see anything there
[12:27] <wgrant> That's the listing of builds.
[12:27] <wgrant> Click on a build you want to know about.
[12:27] <bigjools> tansell: so click on the architecture names in the "Build Status" column
[12:27] <wgrant> Or that.
[12:28] <bigjools> eg https://edge.launchpad.net/~mithro/+archive/ppa/+build/981839
[12:28] <bigjools> it says Estimated build start:  	in 9 hours
[12:28] <tansell> :(
[12:28] <wgrant> That seems about right for today :(
[12:28] <tansell> guess I have been spoilt by opensuse build service
[12:28] <wgrant> No, normally they build immediately.
[12:28] <wgrant> But not for the last week...
[12:29]  * bigjools bitches about bloody typo domain registrants
[12:29] <wgrant> bigjools: Which domain?
[12:29] <tansell> so is there an easy way to build locally? IE build a hardy package on intrepid, etc?
[12:29] <wgrant> tansell: Of course. You want to use pbuilder, probably.
[12:29] <bigjools> wgrant: mispell launchpad in any way and you'll get a holding page :/
[12:30] <wgrant> https://wiki.ubuntu.com/PbuilderHowto
[12:30] <wgrant> bigjools: Ah, yes.
[12:30] <bigjools> lanchpad being my current fave typo
[12:31] <bigjools> I imagine karmic opening up has loaded the PPA queues a bit more than usual as well
[12:32] <wgrant> bigjools: Having less than a third of the usual buildds is probably more of a problem.
[12:32] <bigjools> quite probably :)
[12:32] <wgrant> But yes, the situation has deteriorated since Karmic opened.
[12:32] <tansell> is there a "quick" way to start up an equivalent of the ppa stuff locally? I have a pretty beefy machine and it might make sense to just build locally
[12:33] <wgrant> tansell: See the pbuilder howto that I pointed to. But that will just build them, not put them in an apt-gettable archive.
[12:33] <wgrant> I use pbuilder/sbuild to build and reprepro to generate the archive.
[12:33] <tansell> wgrant, reading it now
[12:33] <wgrant> Although I've been meaning to move to a PPA for a while.
[12:33] <bigjools> tansell: on the bright side, the amd64 builds are only 6 hours from starting, and the lpia 1 hour :)
[12:34] <tansell> I don't care about lpia :)
[12:34] <wgrant> Nobody does, but it's always fastest :(
[12:34] <bigjools> why are your packages building on it then? ;)
[12:34] <wgrant> bigjools: No P-a-s for PPAs :(
[12:35]  * bigjools hides
[12:36]  * wgrant blames bigjools.
[12:36]  * bigjools is used to that
[12:36] <al-maisan> .. but should not really be blamed :)
[12:43] <cyberixa1> Can I somehow get a listing of all projects I have participated in?
[12:43] <cyberixa1> Instead of the top-5 displayed on my profile page.
[14:40] <jtv1> herb, I'd like to silence that translations approver warning—could you run this SELECT on production for me?  https://pastebin.canonical.com/17080/
[14:52] <nicoInattendu> Hi, I m looking for a way to how propose a software for the ubuntu reposirories. I am develloping an animation stop motion software ( https://launchpad.net/luciole).
[15:00] <kiko> nicoInattendu, that's so cool! so first thing would be to package it into a PPA
[15:00] <kiko> nicoInattendu, look at https://help.launchpad.net/Packaging/PPA
[15:01] <nicoInattendu> Yes I have it here https://launchpad.net/~nico-inattendu/+archive/ppa
[15:17] <geser> doesn't LP mail me anymore a copy of a bug I file? (the bugs were filed through the API if it makes any difference)
[15:17] <beuno> BjornT, ^
[15:23] <BjornT> geser: it should. can you paste the code you used to file the bug?
[15:23] <geser> it's requestsync from the ubuntu-dev-tools package
[15:23] <bjsnider> does everything that appears in the repositories always follow ubuntu's packaging standards? because i've found discrepancies
[15:24] <geser> BjornT: I got only the mail about the changes to importance and status but not the "[NEW]" bug mail
[15:26] <geser> BjornT: looking at the headers of this mail I see a references header but never got that mail it references
[15:28] <geser> BjornT: you got my last lines before you disconnected?
[15:29] <BjornT> geser: sorry, no
[15:29] <geser> BjornT: it's requestsync from the ubuntu-dev-tools package
[15:29] <geser> BjornT: looking at the headers of this mail I see a references header but never got that mail it references
[15:29] <geser> BjornT: I got only the mail about the changes to importance and status but not the "[NEW]" bug mail
[15:31] <BjornT> geser: ok, i'll take a look at it. it's either a bug in lp, or something on your side is surpressing mail from yourself.
[15:34] <BjornT> geser: it looks like requestsync isn't using the LP API, though, no? it looks like it either mails the bug, or POST it to the web UI.
[15:34] <BjornT> geser: which bug id was this, btw?
[15:35] <geser> bug 369833 and bug 368465
[15:39] <geser> BjornT: http://bazaar.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk/annotate/head%3A/requestsync shows it uses the LP API (that's also the version in jaunty)
[15:53] <BjornT> geser: oh, right, i looked at the file on the wrong box :)
[16:16] <Laney> is it intentional to not get mails for NEW bugs created with the API?
[16:16] <geser> Laney: I already asked the same and BjornT is looking at it
[16:17] <Laney> oh sweet
[16:17] <Laney> you piqued my interest :)
[16:17] <geser> at least I know I'm not alone with that problem
[16:34] <soren> Is this normal for code imports from sourceforge? https://code.edge.launchpad.net/~vcs-imports/elasticfox/trunk
[16:48] <jelmer> uhm
[16:48] <jelmer> "Launchpad has not been able to mirror this branch. The last attempt was 30 minutes ago. (KeyboardInterrupt) Launchpad will try again in 11 hours. If you have fixed the problem, please ask Launchpad to try again. "
[16:49] <tsimpson> wow, KeyboardInterrupt
[16:50] <exarkun> Are there cameras in the server room? ;)
[17:00] <kiko> jelmer, is that a problem?
[17:00] <kiko> soren, let me check!
[17:00] <kiko> jelmer, well KI means that the operation timed out -- I'm not sure why it's done this crazy way, but there you go
[17:00] <soren> kiko: Fantastic, thank you.
[17:00] <kiko> soren, oh, it's the first import. that really sucks.
[17:00] <jelmer> kiko: Ahh, ok - thanks
[17:01] <jelmer> kiko: Timed out in the sense that the clone took too long or network traffic stalled?
[17:01] <kiko> soren, would an http:// repository work?
[17:01] <soren> kiko: no clue.
[17:01]  * soren tries
[17:01] <kiko> jelmer, it depends on the actual log, what's the branch?
[17:02] <jelmer> kiko: ~jelmer/openoffice/trunk
[17:02] <soren> kiko: Yes, it works with http as well as https.
[17:02] <kiko> soren, let's try
[17:05]  * soren taps fingers, waiting for "as soon as possible" to happen
[17:05] <soren> :)
[17:08] <kiko> soren, changed to http:// and let's hear the music
[17:08] <soren> Yes, I saw.
[17:08]  * soren crosses fingers
[17:09] <kiko> jelmer, this sucks. I bet that branch is as big as the hoover dam
[17:09] <kiko> jelmer, it sucks a bit more that it doesn't tell us why the fuck it didn't mirror
[17:10] <kiko> matsubara, is there a bug filed about bzr branch mirrors fail and expect us to fix them without telling us anything useful towards that?
[17:10] <matsubara> I think there is.
[17:10] <jelmer> kiko: yeah, it's pretty big
[17:10] <soren> jelmer, kiko: fwiw, I can't check out that branch either: bzr: ERROR: Unknown repository format: 'Bazaar development format - group compression and chk inventory (needs bzr.dev from 1.14)\n'
[17:10] <soren> soren@ralph:/tmp$
[17:11] <soren> (output from "bzr branch http://people.samba.org/bzr/jelmer/openoffice/trunk")
[17:11] <jelmer> kiko: You need bzr 1.14 in order to be able to retrieve it
[17:11] <jelmer> s/kiko/soren/
[17:12] <kiko> jelmer, well, we just rolled out 1.14rc2 yesterday
[17:12] <kiko> maybe that's the issue?
[17:12] <kiko> jelmer, can you ask a Question so I can get somebody to fix the issue
[17:12] <matsubara> kiko: bug 193607 perhaps?
[17:12] <jelmer> kiko: One of my other branches in the same format was mirrored fine
[17:12] <jelmer> kiko: Yeah, np
[17:13] <kiko> matsubara, yeah, maybe
[17:32] <tgm4883> can someone please rename this PPA https://edge.launchpad.net/~mythbuntu/+archive/fixes   to fixes-0.21  (alternatively, can someone delete it and we can make a new one?)
[17:52] <thekorn> leonardr, I just branched lp:lazr.restfulclient, should bin/test work without failure for me or does it require some launchpad internals to successfully run this tests?
[18:03] <leonardr> it should work without failure
[18:03] <leonardr> but there might be a dependency it doesn't specify
[18:06] <stefanlsd> Can anyone help me with this - File gears_0.5.18.0~svn3301~dsfg.orig.tar.gz already exists in gears, but uploaded version has different contents? - Trying to upload PPA?
[18:07] <leonardr> thekorn: -^
[18:08] <thekorn> leonardr, ok, cool, I get http://paste.ubuntu.com/161564/
[18:08] <tgm4883> stefanlsd, did you get a new SVN version but not update the changelog?
[18:09] <tgm4883> IIRC, it should also be gears_0.5.18.0~svn3301+dsfg.orig.tar.gz  not gears_0.5.18.0~svn3301~dsfg.orig.tar.gz
[18:09] <tgm4883> to get it through REVU anyway
[18:09] <leonardr> thekorn: that's a very high-level error. how did you get the file?
[18:09] <leonardr> pypi, easy_install, lp:lazr.restful, etc
[18:10] <tgm4883> might need to be dfsg too
[18:10] <stefanlsd> tgm4883: heh. good point. i think thats actually the issue
[18:11] <thekorn> leonardr, sorry, which file? I just folowed the instructions from your last blog post: bzr branch ...; python bootstrap.py; bin/buildout; bin/test
[18:11] <leonardr> ok, you checked it out
[18:13] <leonardr> thekorn, what version of python?
[18:13] <thekorn> leonardr, python2.6.2
[18:13] <leonardr> hm, there might be a problem with restfulclient using an old version of lazr.restful
[18:14] <tgm4883> I'm trying to consolidate the different projects and teams our development team has made.  Is there a way to delete these teams/projects, or who should I talk to about getting this done?
[18:26]  * tsimpson misses all the PPA buildd's
[18:34] <mdz_> kiko,bjorn,et al: thanks for all the recent bugfixes in Bugs!
[18:34] <kiko> mdz_, :)
[18:35] <kiko> tgm4883, I think you need to ask a Question for that -- it's OSA stuff
[18:36] <tgm4883> kiko, ok, a question on LP
[18:36] <kiko> tgm4883, you can talk to me about the merging/consolidation of teams n projects
[18:36] <kiko> what are you looking to do?
[18:36] <tgm4883> well we have several teams made because we needed separate PPA's for things
[18:36] <tgm4883> now we can merge this all since we have multiple ppa's
[18:37] <kiko> that's true
[18:37] <tgm4883> there really isn't a need to have 3 extra teams just for PPA's
[18:37] <tgm4883> and we would rather have it all under one roof anyway
[18:37] <kiko> moving the PPAs around is not trivial, though. you can stack that in the question you're gonna ask
[18:38] <tgm4883> also, over time, there has been a few extra projects made which don't really get used
[18:38] <tgm4883> makes more sense for them to be under a single umbrella project
[18:39] <tgm4883> should I be asking the question here https://answers.edge.launchpad.net/launchpad
[18:47] <kiko> tgm4883, precisely
[18:48] <tgm4883> kiko, thanks, done  https://answers.edge.launchpad.net/launchpad/+question/69398
[18:53] <cumulus007> Launchpad gave me an OOPS
[18:53] <cumulus007> It's id is: OOPS-1216A1747
[18:53] <cumulus007> I was submitting some translations when this happened
[19:07] <Ursinha> cumulus007, this is bug 369858, we're working on it
[19:08] <cumulus007> okay, thanks
[19:21] <dragoon> I've read the docs, but I'm still coming up blank. If my second PPA is at https://launchpad.net/~a.kurtz/+archive/brackup, what should the dput line for incoming be? I thought ~akurtz/brackup/ubuntu but apparently not
[19:24] <LarstiQ> dragoon: ~a.kurts/brackup/ubuntu I'd guess
[19:24] <LarstiQ> dragoon: supposing your changelog mentions the right suite.
[19:25] <dragoon> LarstiQ, "Could not find PPA named 'brackup' for 'akurtz'" - I already fixed the suite changelog issue
[19:26] <LarstiQ> dragoon: the launchpad url you mention has '~a.kurtz' , not '~akurtz'
[19:27] <dragoon> ah, i'm slow today - thanks
[19:28] <LarstiQ> dragoon: that solved it?
[19:28] <dragoon> Well, it's plausible - trying to upload now
[19:35] <dragoon> LarstiQ, yes, that was it, thanks.
[19:36] <kiko> adiroiban, are you around?
[19:39] <adiroiban> hi
[19:41] <adiroiban> kiko: hi
[19:42] <kiko> adiroiban!
[19:42] <kiko> can you help me with https://answers.edge.launchpad.net/rosetta/+question/69297 ?
[19:43] <adiroiban> sure.
[20:00] <leonardr> thekorn, i have a pretty good idea of what happened to you (the installer downloaded an old version of lazr.restful when you installed lazr.restfulclient) but i have no idea how it could have happened
[20:00] <leonardr> do you have a record of the install process you can paste?
[20:11] <thekorn> leonardr, sure, but I've to leave for now, will open a bugreport with a log tomorrow morning
[20:11] <thekorn> leonardr, thanks for looking into it
[20:14] <leonardr> thekorn: thank you
[20:19] <pwnguin> did the old openID provider go away today?
[20:23] <pwnguin> stack overflow claims there's no openID endpoint at
[20:23] <pwnguin> http://login.launchpad.net/+id/kd8nwrb
[20:23] <beuno> pwnguin, that's the old openid format?
[20:23] <beuno> pwnguin, what does your user page say?
[20:24] <pwnguin> i believe the new one is launchpad.net/~username
[20:24] <beuno> I think so, yes
[20:24] <beuno> maybe the old one has been deprecated?
[20:24] <beuno> flacoste, ^
[20:25] <pwnguin> it worked this morning
[20:25] <pwnguin> im tempted to blame our very stupid networking crew here at work
[20:25] <flacoste> hmm
[20:25] <flacoste> there still should be an openid endpoint there
[20:25] <flacoste> it hasn't been deprecated at all
[20:25] <pwnguin> http://stackoverflow.com/users/authenticate <-- thats the page im using
[20:26] <flacoste> pwnguin: and you log in using what? https://launchpad.net/~pwnguin?
[20:27] <flacoste> or whatever your LP username is?
[20:27] <flacoste> it worked for me, fwiw
[20:27] <pwnguin> i made an account with the old url
[20:27] <pwnguin> and they've generously restricted their site based on karma
[20:28] <pwnguin> so the new, sane url is bestowed with no powers
[20:31] <savvas> is it possible to cancel the build queue in PPA?
[20:31] <pwnguin> http://openidenabled.com/resources/openid-test/checkup/start?openid_url=login.launchpad.net%2F%2Bid%2Fkd8nwrb
[20:32] <pwnguin> is it bad form to hand around username hashes?
[20:35] <savvas> stackoverflow works here as well with openid
[20:35] <pwnguin> savvas: with the hash form or the new urls that make sense?
[20:36] <savvas> I don't know what  you mean, I used http://launchpad.net/~medigeek :)
[20:37] <pwnguin> a long long time ago, LP openid used a strange hash format
[20:38] <pwnguin> i used that format on a few sites, which associated some privlidges with it
[20:38] <savvas> and you used that, and now stackoverflow shows as if you have two separate openid accounts?
[20:38] <pwnguin> yes
[20:39] <savvas> well you could file a bug asking launchpad to merge your old "hashy" openid account with the new one (is that possible?)
[20:40] <savvas> sorry, a question not a bug :)
[20:40] <pwnguin> or i could open a bug with stack overflow
[20:40] <savvas> http://answers.launchpad.net/launchpad
[20:40] <savvas> or that :)
[20:40] <pwnguin> i mean, i really hate the old url and im glad it's fixed
[20:40] <savvas> I think your solution is more appropriate, since they are the ones that have the data
[20:40] <pwnguin> technically, there's some redirection facilities within openID
[20:52] <kiko> savvas, cancel the build queue?
[20:52] <kiko> pwnguin, I think the issue is actually on their side
[20:52] <pwnguin> kiko: the openID test site failed too?
[20:55] <savvas> kiko: yes, I had some packages that I've regretted uploading them and deleted them. they're still on the build queue however: https://edge.launchpad.net/~medigeek/+archive/experimental/+builds
[20:55] <savvas> that is, all except 0.3.0git200904300722-0~ppaintrepid2 and 0.3.0git200904300722-0~jaunty2
[20:56] <kiko> savvas, I don't care if they build and fail. do you? :)
[20:56] <kiko> pwnguin, sorry, I lost your point?
[20:56] <savvas> kiko: honestly? no :p
[20:57]  * kiko high fives savvas and welcomes him to his club of evil
[20:57] <savvas> hehe
[20:57] <savvas> I thought I might be missing something, but thank god I'm not :P
[21:01] <pwnguin> kiko: one might hope that openID enabled's test consumer would be a litmus test for where things went wrong.
[21:02] <kiko> flacoste, could we have a regression in the legacy endpoints?
[21:03] <C10uD> hi
[21:03] <C10uD> i lost my gpg key
[21:04] <C10uD> is there a way i can get it back or i need to create a new one for pushing to launchpad?
[21:04] <kiko> there is no way
[21:05] <kiko> are you sure you lost it?
[21:05] <pwnguin> if there was a way to recover gpg keys, it wouldnt' be very secure :)
[21:05] <C10uD> yes i forgot to save some hidden folder while changing the hard drive
[21:06] <C10uD> maybe it was saved somewhere in my launchpad project branch :p
[21:06] <C10uD> (local branch)
[21:06] <pwnguin> launchpad should just have the public key, no?
[21:07] <duck_tape> are LP mailinglists having issues?
[21:07] <C10uD> i guess so, i don't know too much about security...anyway now i just recreate one and add to launchpad am i wrong?
[21:08] <duck_tape> i sent an email to a ML that I am a member of > 3hrs ago
[21:08] <duck_tape> and have not seen it
[21:08] <pwnguin> duck_tape: is this the first email?
[21:09] <duck_tape> yes
[21:09] <pwnguin> check your spam folders?
[21:09] <duck_tape> first outgoing
[21:09] <duck_tape> i have been receiving emails from the list for a few days now
[21:10] <duck_tape> i received an email that seems to have been sent after I sent mine out but my email is still missing
[21:10] <bjsnider> shouldn't ubuntu packages be named as follows: packagename-version-0ubuntu1?
[21:11] <pwnguin> bjsnider: 0 and 1 are variable, and that whole suffix only applies if you made any signficiant changes
[21:12] <bjsnider> right, leaving the fact that the numbers are variable out of it though
[21:12] <bjsnider> why is kaffeine's package breaking the rules?
[21:15] <pwnguin> wait
[21:15] <pwnguin> packages should be named package
[21:15] <bjsnider> kaffeine-0.8.7-1ubuntu5 does not conform to the standards
[21:16] <bjsnider> 0.8.7-1 is the debian version number
[21:16] <bjsnider> it should be 0.8.7-1-0ubuntu5
[21:17] <pwnguin> the fun thing about versions is that they're montonically increasing
[21:17] <bjsnider> also the source tarball is quite a bit different than the one i pulled out of svn. files are in different places and so forth. i thought the tarballs should be left alone
[21:18] <pwnguin> you might check policy to see where this package came from
[21:18] <pwnguin> if its a ppa or mediabuntu, all bets are off
[21:19] <bjsnider> it's the regular one in universe or wherever
[21:19] <bjsnider> it was taken from debian's version by the same guy i think
[21:19] <pwnguin> oh right, im still running 8.10 on my desktop
[21:19] <bjsnider> http://packages.ubuntu.com/fi/source/jaunty/kaffeine
[21:20] <kiko> duck_tape, there shouldn't be any issues with our mailing lists, no
[21:20] <pwnguin> bjsnider: this might be a question beter suited for kubuntu-devel
[21:20] <duck_tape> kiko: tx i guess my msg must be awaiting approval or some such
[21:20] <pwnguin> or motu, im not sure
[21:21] <bjsnider> do you agree that the version number appears wrong?
[21:21] <pwnguin> im not sure
[21:21] <pwnguin> its been too long since i last touched packaging
[21:22] <pwnguin> maybe 0 is the debian modifier and appending ubuntu1 is the ubuntu modifier?
[21:37] <omegamormegil> I think the Launchpad Report a Bug dialog should recommend that people go back and report bugs with apport (if possible).  Right now, the only recommendation to use apport is UNDER the bug description box.  Someone reporting a bug don't even see it until after they've spent time reporting the bug manually.  Also, it doesn't mention the command line tools like ubuntu-bug and specifically apport-collect which would be rea
[21:37] <omegamormegil> lly useful to someone who had just finished polishing a bug report on that page.
[21:44] <matsubara> omegamormegil: bug reporting guidelines are controlled by the project/distribution bug contacts. You can talk to bdmurray to get those updated or discuss changes about it on #ubuntu-bugs
[21:45] <omegamormegil> OK, thanks.
[21:47] <flacoste> pwnguin: did you try that URL in another site?
[21:48] <pwnguin> http://openidenabled.com/resources/openid-test/diagnose-server
[21:49] <sekinto> Running "bzr push lp:<something> --use-existing-dir" makes a new branch, but the branch page says "This branch has not been pushed to yet." and shows no revisions.
[21:50] <pwnguin> flacoste: livejournal also claims it doesn't work
[21:50] <mwhudson> sekinto: it will within a minute or two
[21:50] <pwnguin> i wonder if i just have the url wrong somehow.
[21:51] <flacoste> pwnguin: what about if you use https://login.launchpad.net
[21:51] <sekinto> mwhudson: So it did! I guess I should be more patient next time.
[21:51] <mwhudson> sekinto: we should also display a nice message in that situation
[21:52] <mwhudson> in fact, i have a note here already to file a bug about this...
[21:52] <pwnguin> flacoste: that works...
[21:52] <mwhudson> (not to mention we should make the problem go away...)
[21:52] <flacoste> pwnguin: and that's easier to remember ;-)
[21:52] <pwnguin> sure is
[21:53] <pwnguin> openID is insane
[21:54] <pwnguin> i gave a presentation on it to my advanced www technlogies course a few years ago. clearly i havent kept up with it
[21:58] <pwnguin> flacoste: thanks for the tips
[22:09] <soren> kiko: \o/ Elasticfox import worked! Thanks!
[22:36] <kiko> soren, heh, that's great to hear ;)
[22:36] <kiko> https sucks part 4912
[22:38] <BasicOSX> Where can I find out more about what actually happens when you set your project Bug Tracker to SourceForge's bug tracker? I see the overview of SourceForge.net and there are internal bug numbers and remote bugs. I'd like to understand this concept further.
[22:39] <wgrant> I don't think anything actually happens, although it's possible that it's used when upstreaming bugs.
[22:40] <wgrant> BasicOSX: But do you know how Launchpad bugwatches work?
[22:40] <BasicOSX> No :-) first project where bugs aren't on LP proper
[22:41]  * wgrant tries to find the wiki page.
[22:42] <BasicOSX> I'm trying to find more info as well
[22:42] <wgrant> Basically, when you create a task for a project that doesn't use Launchpad for bug tracking (using 'Also affects project...'), it will ask you for a bug URL.
[22:42] <wgrant> You enter the remote URL there, and it will automatically sync the status from the remote bug.
[22:44] <BasicOSX> wgrant so I set the project to track bugs in Launchpad or "In a registered bug tracker: SourceForge.net Tracker" ?
[22:45] <wgrant> BasicOSX: If they're tracked on SourceForge.net, set it to SourceForge.net.
[22:46] <BasicOSX> LP tour talks about cross-project bug tracking, but just sales "fluff" not much details
[23:03] <BasicOSX> Reporting a bug when LP isn't the tracker is not intuitive. Sorry to pester, but any links to more details on cross-project bug tracking?
[23:05] <kiko> BasicOSX, I realize it kinda sucks for reporting bugs.
[23:06] <kiko> BasicOSX, but the linking works best right now for keeping track of bugs anywhere
[23:06] <BasicOSX> I cannot find a way to link bugs, is there something documented for me to read so I know how to do that?
[23:07] <kiko> yep
[23:07] <kiko> hang on there
[23:08] <kiko> https://help.launchpad.net/Bugs/MultiProjectBugs
[23:08] <kiko> and where else..
[23:09] <BasicOSX> On my project, I click "Bugs"->Report a Bug and I get warning "OSXTrek does not use Launchpad as its bug tracker" ... official bug tracker, SourceForget.net Tracker but the link there is to http://sourceforge.net, since I plugged in the project ID on SF could the link on the Report Bug page on LP point to the SF bug tracker specified by the project ID?
[23:12] <BasicOSX> kiko:  so it looks like I should change the project to use LP as bug tracker and then link to SF bug tracker? Right now I have the project configured to use SF as the bug tracker.
[23:17] <wgrant> BasicOSX: Why would you report a new bug in Launchpad?
[23:17] <wgrant> The normal case for bugwatches is creating multi-task bugs, where another project that does use Launchpad is affected by the same bug.
[23:18] <matsubara> or a the same bug in a ubuntu package for instance
[23:18] <wgrant> See the example on that wiki page.
[23:18] <wgrant> s/project/bug target/
[23:48] <BasicOSX> Attempting to add an Affects to a bug report, click "Also affects project", type in Project, click Continue, I get "Oops!"  (Error ID: OOPS-1216D2336)