[00:07] <timClicks> hi all, can anyone send a link to the guide on how to link the sourceforge tracker (https://bugs.launchpad.net/bugs/bugtrackers/sf) to the launchpad project? (https://launchpad.net/sahana)
[00:20] <thumper> timClicks: I think you link bugs, not projects
[00:20] <wgrant> You can also link projects.
[00:20] <wgrant> On +edit, you can select the bug tracker.
[00:20] <timClicks> thumper: have added this question https://answers.launchpad.net/launchpad/+question/79059
[00:21] <wgrant> Ah, that's different.
[00:21] <timClicks> I'm a big fan of LP and am trying to lessen the transition costs for the team
[00:22] <timClicks> wgrant: thanks, I'll send that through
[02:10] <SamB> mwhudson: ah, right.
[02:10] <SamB> mwhudson: I guess you would call that "working"?
[02:33] <lamalex> What happened to the lp bug emails? they used to have the project name in the subject
[02:33] <lamalex> the new ones don't and it's a huuge regression
[02:34] <wgrant> lamalex: They never did for me.
[02:34] <wgrant> And I hope they never do.
[02:35] <wgrant> I don't want subjects cluttered with useless information; my filtering rules already tell me the project
[02:36] <mwhudson> from which we swiftly deduce that all launchpad bugs developers have a drinking problem
[02:36] <mwhudson> (i.e. they can't please anyone any of the time)
[02:36] <wgrant> Plus bugs don't have a project.
[02:36] <wgrant> They have lots.
[02:36] <wgrant> And lots of packages.
[02:38] <lamalex> hm yes i was confused about that
[02:40] <lamalex> how do you filter your big mail?
[02:40] <lamalex> s/big/bug. got my net is terrible tonihght.
[02:41] <wgrant> lamalex: Just fairly basic sieve rules.
[03:08] <spm> lamalex: using procmail; and on 1. "* ^X-Launchpad-Bug:" (simple match that this is a bug report, don't care what for as #2 fixes that) 2. "* ^X-Launchpad-Message-Rationale:.*<why>"
[03:08] <spm> so in my case the bugs I tend to actually care about match on: ^X-Launchpad-Message-Rationale:.*@canonical-losas
[03:09] <spm> everything else, for me, tends to be noise, so gets thrown into a lower priority folder to deal with later.
[03:10] <wgrant> I filter by both target and importance. I get important ones somewhat like spm, except with ^X-Launchpad-Message-Rationale: Subscriber$.
[03:10] <timblack1> I'm trying to import a Subversion repository into Launchpad.  The repository requires that I enter the username "anonymous" to checkout a copy.  Launchpad marked my attempted import invalid for this reason:  "Rejected: repository demands authentication"  So I tried entering this URL into the import system:  http://anonymous:@joomlacode.org/svn/rsgallery2.  This works as a svn checkout url on my local machine, but Launchpad tells me "A user
[03:11] <wgrant> timblack1: Your message got cut off after "A user"
[03:11] <timblack1> ...name may not be specified in the URI."  Is there any way for me to import this repository?
[03:16] <fta> spm, i have some filters starting with ^(X-Launchpad-Bug|X-launchpad-(question|branch)).. too bad the l vs L :P
[03:17] <spm> fta: heh. yeah, I need a LOT of filters to keeep LP email under control. stuff I need to work on/for - LP User Answers for example; vs personal project answers etc. Gets messy...
[03:19] <fta> spm, same here, i have ~80 procmail rules ubuntu related
[03:19] <spm> yah. fun fun fun...
[03:20] <mwhudson> timblack1: ask a question on answers.launchpad.net/launchpad-code with all the details pls
[03:20] <fta> and i tend to abuse of regexps
[03:20] <timblack1> Ok, thank you mwhudson!
[03:24] <fta> i wish i had a single page to monitor all my ppas/builds, i'm tired of reloading so many pages. Something with *1* line per project, all the build status in column
[03:24] <fta> less texts, more icons and links
[03:25] <SamB> wouldn't one line per package be better ?
[03:25] <wgrant> fta: The script that generates http://qa.ubuntuwire.org/ftbfs/ could be fairly easily altered to do that.
[03:28] <fta> i mean, something between https://edge.launchpad.net/~fta/+ppa-packages and https://edge.launchpad.net/~chromium-daily/+archive/ppa
[03:28] <fta> but not 4 lines per project
[03:29] <fta> just package name, version, publish date, and some rows of icons
[03:30] <fta> btw, in /+ppa-packages, the Status is wrong, it's always Failures = None
[04:49]  * kfogel is away: sleep
[09:04] <iammyr> Hi everyone
[09:10] <iammyr> i'd like to know if the custom GET method "findSimilarBugs" of the Rest API can be applied only to bugs stored in Launchpad or is it sufficient to provide info such as a list of tags (which may be taken from bugs stored anywhere) to retrieve similar Launchpad-stored bugs.
[09:11] <iammyr> That is..I have an external dataset and I'd like to link my bugs to Launchpad's ones, then I need to search in there for similar bugs.
[09:18] <wgrant> iammyr: I don't think you can do that now, but a feature that will be implemented soon requires that functionality.
[09:19] <wgrant> So it should appear soonish.
[09:20] <iammyr> do you know about other bug datasets available online which I could search for bug similar to mine?
[09:28] <thekorn> hi, are there plans to update staging.lp.net? it's about 700 revisions behind edge.lp.net
[09:31] <maxb> thekorn: Actually I think it isn't, it's just an artefact of the way bzr revision numbers from different branches are not comparable
[09:32] <sianis> hello
[09:33] <sianis> https://code.edge.launchpad.net/~mvo/ddtp-ubuntu/ddtp-ubuntu - why do lp not update this branch?
[09:35] <thekorn> maxb: ok, maybe 700 is a bit pessimistic ;) but staging is missing the ajax bits for task editing and adding comments
[09:36] <thekorn> which is a good indicator to say "staging is using an old version" :)
[09:37] <thekorn> ehm, maybe not, ajax for tasks is there
[09:43] <maxb> Steady on, ajax commenting only landed on stable less than 24 hours ago!
[09:44] <maxb> IIUC the process goes something like this: automated buildbots will merge stable into db-devel, and then promote db-devel to db-stable, which then ends up on stable at the next redeploy
[09:51] <thekorn> ok, thanks maxb. staging beeing a few hours or even days behind is not a problem for me. I think I just got confused by the different revisions. So, nevermind
[10:34] <iammyr> is there anyone who knows an online available and query-able bug dataset?
[10:35] <iammyr> which allows to perform searches over bugs by mean, for example, of their tags?
[10:35] <iammyr> I was told Launchpad can't yet allow this search
[12:23] <geser> is it a bug that I get emails for comments on duplicate bugs with only the bug number in subject but no description? or was it caused by something else?
[12:24] <wgrant> geser: I noticed that. I bet it's the AJAX.
[12:24] <wgrant> And I think I might have seen a bug about that last week.
[12:24]  * wgrant hunts.
[12:25] <andv> bigjools, are you really sure not anyone wish to be emailed automatically for such things?
[12:25] <andv> bigjools, I mean it won't be an high traffic spam of accepted mails
[12:26] <geser> wgrant: just strange that it only happened after the bug got duped, the comments before had the description in the subject
[12:27] <intellectronica> i just noticed that too
[12:27] <wgrant> Bug #381559
[12:27] <bigjools> freenode FTW
[12:27] <andv> bigjools, did you read?
[12:28] <geser> wgrant: just strange that it only happened after the bug got duped, the comments before had the description in the subject
[12:28] <wgrant> geser: I shall check the code.
[12:28] <wgrant> geser: Remember that edge got updated a few hours ago.
[12:28] <intellectronica> wgrant: i'm not sure that's related to the subjectless comment emails, but it could be
[12:29] <bigjools> andv: I did, but perhaps I don't understand what point you're making?
[12:30] <andv> bigjools, why when a sync get processed only the Changed by: field is mailed?
[12:30] <andv> bigjools, that's the point
[12:30] <wgrant> Autosyncs suppress emails entirely, don't they?
[12:30] <andv> yes
[12:31] <andv> manual syncs process Changes by: field only instead
[12:31] <bigjools> and you think it's appropriate to email Maintainer: as well, for manual syncs?
[12:31] <andv> yes
[12:31] <andv> also for automated import ones
[12:32] <andv> wgrant, what do you think?
[12:32]  * bigjools knows what wgrat will say
[12:32] <wgrant> andv: It would be insane.
[12:32] <bigjools> totally insane
[12:32] <geser> wgrant: how many hours is "a few"? less than 3?
[12:32] <andv> bigjools, why?
[12:32] <wgrant> Insane and suicidal.
[12:32] <wgrant> geser: 0800UTC, IIRC.
[12:32] <wgrant> Or was it BST...
[12:33] <andv> wgrant, why do you think it's insane?
[12:33] <bigjools> andv: do you think that all Debian maintainers would like more LP email?
[12:33] <wgrant> Debian maintainers would be correctly furious.
[12:34] <geser> andv: some DD don't want even mails about Ubuntu changes to their packages and you want to mail them about every sync of their packages?
[12:34] <bigjools> andv: this is why I said it should be strictly "opt-in"
[12:34] <andv> bigjools, wgrant, geser: should be done as an option then like julien said
[12:34] <andv> bigjools, yeah, right
[12:35] <wgrant> intellectronica:
[12:35] <wgrant> +            parameters: {
[12:35] <wgrant> +                subject: '',
[12:35] <wgrant> +                content: comment_input.get('value')
[12:35] <wgrant> +            }
[12:35] <andv> bigjools, I hope it will be done sooner or later
[12:35] <bigjools> andv: are you happy with the dupe now?
[12:35] <wgrant> intellectronica: The subject is explicitly empty, presumably to avoid that bug.
[12:35] <wgrant> So it is really that bug.
[12:35] <geser> andv: opt-in is ok, but opt-out is a no-go
[12:35] <bigjools> andv: I hope it will be done by the end of the year
[12:35] <andv> bigjools, yep, looks fine now
[12:35] <andv> bigjools, sounds great ty
[12:35] <andv> geser, yep
[12:35] <bigjools> andv: great, thanks for your patience and understanding
[12:36] <andv> bigjools, thanks to you :) feel free to close the bug
[12:36] <bigjools> well it's duped, so no need :)
[12:36] <intellectronica> wgrant: yeah, but that's not the problem (or at least, not where it should be fixed)
[12:36] <andv> true, fine then
[12:36] <intellectronica> we should identify that the subject is empty and prepare a 'Re: blah' subject
[12:36] <andv> bigjools, good work and sorry for bothering
[12:36] <wgrant> intellectronica: I suppose.
[12:37] <bigjools> andv: no problem at all!  Thanks for the bug report, it reminded me of the problem :)
[12:37] <andv> ;)
[12:38] <andv> at least the report has been usefull for something
[12:38] <maxb> What's the rationale for autosyncs not emails adjective-changes@ ?
[12:39] <maxb> s/emails/emailing?
[12:39] <wgrant> It'd be very noisy, though I'd like them to be sent.
[12:39] <wgrant> This is why we have structural subscriptions.
[12:40] <geser> at least after DIF it would be nice to have them on -changes
[12:41] <wgrant> geser: Autosyncs don't happen after DIF.
[12:41] <geser> in the past (till Jan 2006) they were announced to ubuntu-changes-auto, don't know why it stopped
[12:41] <geser> true
[12:41] <wgrant> geser: Ubuntu moved to Soyuz in February 2006.
[12:51] <Laibsch> Can you please suggest some example scripts on how to manipulate launchpad bugs (leave comments, etc.) via the command line rather than through the web interface?  I used to have some python scripts based on https://wiki.ubuntu.com/BugHelper/Dev/python-launchpad-bugs/Examples but they don't work anymore.
[12:51] <wgrant> Laibsch: https://help.launchpad.net/API/launchpadlib
[12:52] <ondrej> hi
[12:52] <ondrej> i would like to delete a project at launchpad
[12:52] <ondrej> how can i do that?
[12:53] <Laibsch> wgrant: that is a lot of nice docu
[12:53] <Laibsch> but it doesn't tell me (yes, I'm stupid ;-)) how to add a comment to a bug
[12:53] <Laibsch> I want something simple
[12:54] <Laibsch> Are there no examples for simple stuff based on launchpadlib?
[12:54] <Laibsch> I'm not expecting to be spoon-fed, but I don't want to read the complete launchpadlib docu, either
[12:55] <wgrant> Laibsch: It shows you how to change the status and a couple of other things. Look at https://edge.launchpad.net/+apidoc for more.
[12:56] <Laibsch> that's even longer
[12:56] <Laibsch> and still no example
[12:56] <Laibsch> I'm not complaining, but I think you understand that is not what I'm looking for
[12:56] <Laibsch> it's really too complicated for me
[12:56] <Laibsch> sorry
[12:57] <wgrant> An example can't be given for every method and attribute. You want to get hold of a bug object, and call the appropriate method on it.
[12:57] <Laibsch> I'm not expecting that
[12:57] <wgrant> newMessage is the appropriate method, it appears.
[12:57] <Laibsch> well, my python foo is about strong enough to take a ready-made and complete (!), working script and adapt it slightly
[12:57] <Laibsch> so, I absolutely need a working example
[12:58] <Laibsch> complete documentation on how to stitch everything together is nice and very important, but it won't help me :-(
[13:00] <geser> Laibsch: http://paste.ubuntu.com/247176/ is the main part off my very simply script to ACK sync requests
[13:00] <Laibsch> cool, thanks
[13:08] <Laibsch> geser: can you paste the stuff for authentication (obfuscating any sensitive data, of course)?
[13:10] <geser> Laibsch: there is nothing secret in there: http://pastebin.ubuntu.com/247184/ is the complete script
[13:18] <Laibsch> Hey, awesome, it's working
[13:18] <Laibsch> Thanks, geser!
[13:20] <geser> you might want to replace EDGE_SERVICE_ROOT with STAGING_SERVICE_ROOT for testing to not manipulate real bugs
[13:51] <bac> good morning, launchpad!  i'm the designated help guy for the day, so ask your questions here.
[13:51] <gnomefreak> oh that is weird, cool but weird (the new "add comment" part)
[13:54] <Laibsch> geser: Every change I make is done in a single commit.  How can I collect all changes to be done at once?  Do you understand what I mean?
[13:54] <wgrant> Laibsch: The Launchpad API does not have transactional behaviour.
[13:54] <wgrant> All operations happen as you perform them.
[13:54] <Laibsch> so, there is no way around that?
[13:55] <Laibsch> I'm asking because I don't want to clutter up the webpage too much, if possible
[13:56] <wgrant> What is cluttered? The activity log inlined on the bug page?
[13:57] <Laibsch> yes
[13:57] <Laibsch> three boxes instead of one
[13:57] <wgrant> That's a bug that affects the web UI too now.
[13:57] <Laibsch> the connection also doesn't become immediately clear
[13:58] <wgrant> The items are meant to be grouped more aggressivel.
[13:59] <Laibsch> Well, I can currently click on the right down arrow and do all of the following at once in the web UI: change project, change assignee, change status, change importance and make a comment
[13:59] <gary_poster> Laibsch: no, there's not a way around it.  If you have a use case for transactions, send it to launchpad-dev.  If this is just a UI thing, that probably can be worked around--for instance, collapse the activity log, maybe?  Transactions in a RESTful system are somewhat of a big deal to implement, technically and/or philosophically, depending on the approach.
[13:59] <gary_poster> Really compelling use cases would probably help us to decide to work on that.  (Alternatively, maybe you want to help on implementing this, which would need to be coordinated with the other people working on the RESTful bits)
[13:59] <Laibsch> that is up to five boxes
[14:00] <wgrant> Laibsch: That is going away soon.
[14:00] <Laibsch> no, it's more aesthetical
[14:00] <Laibsch> gary_poster: ^
[14:00] <Laibsch> It does help a bit in immediately understanding changes that belong together
[14:00] <Laibsch> but as wgrant said, improvements are in the pipeline
[14:02] <Laibsch> the thing is, the mails I receive *do* group the changes I've made
[14:02] <gary_poster> Laibsch: gotcha.  I don't know what you are doing, so my suggestions are probably naive, but that hasn't stopped me before. ;-) Maybe having a semantic summary you provide that can be expanded to see the atomic Launchpad logs would be a reasonable approach.  ...or maybe the improvements in the pipeline are sufficient. :-)
[14:03] <Laibsch> It may be that I did task.lp_save too soon
[14:03] <wgrant> Laibsch: Ah. If you're just setting attributes on one object, you could just delay the call to lp_save(). But that won't help you for calling methods or altering multiple objects.
[14:03] <gary_poster> mm, yeah. you can group changes like that (on a single object).
[14:05]  * wgrant sets the Soyuz tests running, and disappears for the evening.
[14:46] <kayess> Hiya jtv :)
[14:47] <jtv> hi kayess  :-)
[16:20] <SamB> okay ... why the heck is this showing so many bugs for each branch?
[16:20] <SamB> https://code.edge.launchpad.net/~jelmer/bzr-svn/0.6/+merges
[16:28] <intellectronica> SamB: well, either someone linked these branches to many bugs, or it's a bug
[16:30] <SamB> intellectronica: actually, I think the issue is that it's including associatins that are already merged into lp:bzr-svn
[16:30] <SamB> when it should only mention *new* associations
[16:30] <intellectronica> yeah, but i would think that we should only care about top-level associations
[16:31] <intellectronica> it doesn't make much sense to link to merged associations, or trunk will always be linked to gazillion bugs
[16:31] <intellectronica> rockstar: maybe you have a clue? ^^^
[16:33]  * rockstar looks
[16:34] <rockstar> Looks like it is a bug.  Luckily, that page is going to be removed in 3.0.
[16:35] <rockstar> If you look at the page for those branches, they don't show those bugs.
[16:49] <james_w> I filed that bug the other day
[18:43] <Daviey> Is it correct that the buildd queue for amd64 = 0 and i386 is 282?!
[18:45] <maxb> Daviey: You need to be aware that architecture-neutral packages are built in the i386 buildds - then it makes sense
[18:45] <Daviey> ofc. :(
[19:23] <zaytsev> Hello
[19:24] <zaytsev> I'm trying to get grips with PPA and apparently just screwed my first upload by typing incoming in my .dput.cf
[19:25] <zaytsev> Now that I've corrected the mistake dput refuses to re-upload the package since it's already uploaded...
[19:25] <zaytsev> Anybody please advice
[19:25] <micahg> bump the small version
[19:26] <micahg> it just needs to be slightly bigger
[19:26] <zaytsev> Like ~ppa1 -> ~ppa2 + debuild -S  ?
[19:26] <micahg> yep :)
[19:27] <zaytsev> Thanks, going to try that. I have another concern btw
[19:28] <zaytsev> Now that I've uploaded the thing how do I know for which distros it's going to be built?
[19:28] <zaytsev> When I type dch -i it automatically adds something like mc (2:4.7.0-pre1-1~ppa2) jaunty; urgency=low to the changelog
[19:28] <micahg> ppas can only be built for ubuntu at this point AFAIK
[19:28] <zaytsev> Does it mean that this package is going to be build for Jaunty?
[19:29] <micahg> yep
[19:29] <micahg> whatever version is specified there in the changelog
[19:29] <zaytsev> micahg, sorry wrong term, I obviously meant the version of Ubuntu
[19:29] <micahg> ok, np
[19:30] <zaytsev> OK, now the question is whether it is possible to make it build for all supported versions at once?
[19:30] <micahg> nope
[19:30] <micahg> not at the moment
[19:30] <micahg> usually they will either increment the ppa number for each version build
[19:31] <micahg> or do ppa0.09.04, ppa0.08.10,...
[19:31] <zaytsev> Aha, so I will need to redo the whole thing for Hardy / Jaunty, fair enough. Is there a switch for dch -i so that it adds entries of other dists?
[19:31] <micahg> you might want to check in the #ubuntu-motu channel for that
[19:31] <micahg> idk
[19:32] <micahg> not even redo
[19:32] <zaytsev> I'm OK with ~ppaN thing, I just want to provide Ubuntu package for every bleeding edge upstream release
[19:32] <micahg> it could just be as simple as dch -i and edit the version
[19:33] <micahg> and just add a changelog entry for each, backport to x
[19:33] <zaytsev> Aha, I see, so I don't even need to do separate changelogs for different versions?
[19:34] <micahg> zaytsev: depends if you want to change anything for the versions
[19:34] <zaytsev> Nope, no changes, just make LP to rebuild the package for different versions
[19:35] <micahg> then no, you can use the same changelog for everything
[19:35] <micahg> you might want to note no source changes as well
[19:35] <zaytsev> Cool!!! I'll give it a try! Thanks a bunch, man :-)
[19:41] <zaytsev> Oh great =( now I screwed things up because it deleted orig.tar.gz :(
[19:42] <zaytsev> This packaging thing is so unbelievably complicated for a poor humble RH packager
[19:44] <LarstiQ> awww :)
[19:44]  * LarstiQ reads backlog
[19:45] <LarstiQ> zaytsev: what do you find complicated?
[19:46] <zaytsev> Could someone please clarify whether *always* I need to do debuild -S -sa everytime I upload a package or I will have to do  debuild -S  after the first successful upload?
[19:46] <zaytsev> The orig.tar.gz of the package I'm trying to rebuild is not in the repos.
[19:47] <LarstiQ> zaytsev: in general, -sa on he first upload of that upstream version, -sd after (or not supply anything and let it detect it)
[19:48] <zaytsev> LarstiQ, thanks! It finally accepted my fist package. I will try -sd on the next upload (for a different Ubuntu version)
[19:49] <LarstiQ> zaytsev: you can also just leave it off, is what I do
[19:49] <SamB> hmm ... it seems like it would be a good idea for launchpad to prod high-priority bugs that haven't been touched in months?
[19:49] <LarstiQ> SamB: janitor?
[19:50] <SamB> what does that do?
[19:50] <zaytsev> Uhm, how it is going to detect whether I already uploaded it or not? I've missed -sa last time and it didn't complain on upload but I received a rejection email afterwards
[19:50] <zaytsev> LarstiQ, actually it is the number of the control files and strange helper utilities that scares me so much.
[19:51] <SamB> when I say "prod", I mean roughly "add a comment reminding the subscribers how long this bug has gone unresolved without comment at >=high priority"
[19:52] <zaytsev> We only have a single SPEC file and rpmrebuild -bs. This produces an SRPM file which can be then uploaded to a Koji farm via the web interface
[19:55] <LarstiQ> zaytsev: for the basics you only need debian/rules and debian/control
[19:56] <zaytsev> I understand. But it's a whole new world, and it's very different
[19:57] <LarstiQ> right
[19:57] <LarstiQ> zaytsev: reading the Debian policy might enlighten parts of that world
[20:00] <zaytsev> Oh yeah
[20:01] <zaytsev> The Intrepid upload was successful
[20:20]  * bac -> lunch
[20:37] <mrooney> sinzui: hey, I saw your reply on the blueprints subscription. is there a particular weekend time you are available to mentor me on IRC or something?
[20:38] <sinzui> mrooney: no particular one. This weekend is fine, I hack on my own launchpad agenda on weekends.
[20:42] <mrooney> sinzui: cool! I wonder how easy it is to clean up some of UI stuff as well, and have ajax changes to milestones and such
[20:42] <mrooney> though if that is already targeted for 3.0 it may not be as important
[20:43] <sinzui> mrooney: The order of magnetude form simple to hard is text change, TAL/METAL change, View Change, Model/adapter change, schema change, ajax change
[20:44] <sinzui> mrooney: It would be nice have some ajax operations on milestone listings and the owner of a project may want to create a milestone directly on the bug page.
[20:55] <mrooney> sinzui: so there is that list of like 8 things, Milestone, Driver, Approver, et cetera, with edit buttons next to each if you have permissions
[20:56] <sinzui> no
[20:56] <mrooney> no?
[20:56] <mrooney> I mean if you visit the blueprint page
[20:56] <sinzui> Oh yeah, that is insane
[20:57] <sinzui> either that page needs the inline edit widget everywhere or they should be moved to a single edit page.
[20:57] <sinzui> both actually
[20:58] <sinzui> since we want everything editable inline, then a single page for browsers we do not support
[20:59] <sinzui> mrooney: Adding an inline widget requires exposing blueprints to API first (because our AJAX talks over REST)
[20:59] <mrooney> I see
[20:59] <mrooney> one possibility is to kill the individual edit pages, and replace the "edit" button with their respective drop-down / text field
[21:00] <mrooney> so one that page, if I have permissions, all those fields are editable at the same time, with a save button or something
[21:00] <sinzui> mrooney: exposing API means annotating the classes and methods that should be public, and adding a test to prove it works. It is not hard, but is best done in several small branches as needed
[21:01] <days_of_ruin> I am trying to set up automatic exports of translations to a bzr branch that is owned by me, I set it up yesterday and AFAIK it hasn't updated it with the translation files.
[21:01] <sinzui> mrooney: we do not want a separate implementation that requires differnt rules to code. There is nothing to share in that approch
[21:01] <mrooney> I see yes, ajax is probably optimal
[21:02] <mrooney> days_of_ruin: it runs at the same time every day, if it hasn't been 24 hours perhaps it didn't occur yet?
[21:04] <days_of_ruin> mrooney, what time of the day does it run?
[21:07] <mrooney> that, I don't know
[21:38] <zaytsev> Hmm... Could someone please advise whether it is possible to rely on the packages from backports in builders
[21:38] <zaytsev> I badly need debhelper 7 on hardy, because otherwise dh_install fails :(
[21:59] <micahg> zaytsev: you can check where your ppa looks for its sources
[21:59] <micahg> *change
[21:59] <zaytsev> Wow
[21:59] <zaytsev> Sounds interesting
[22:00] <zaytsev> micahg, how would I do that?
[22:00] <micahg> zaytsev: Edit Dependencies on your ppa home page
[22:00] <zaytsev> Cool!!! Thanks
[22:01] <zaytsev> I'll have another try
[23:03] <cody-somerville> Is there a bugzilla launchpad plugin for bugzilla 3.4?
[23:31] <synic> Is there a way to manually expire bugs that are inactive for a certain amount of time?
[23:31] <synic> (but in bulk)
[23:33] <fta> cody-somerville, iirc, it stopped there: mozilla 481161
[23:35] <cody-somerville> fta, hmm?
[23:38] <fta> cody-somerville, well, that was the answer from bugzilla devs (and mozilla heads jumped in), but maybe it exists as a 3rd party thingy, no idea
[23:38] <cody-somerville> fta, There is a bugzilla launchpad plugin
[23:39] <fta> yep, but last time i spoke to the bugzilla devs, they didn't want it.
[23:42] <cody-somerville> fta, I'm not really interested if th bugzilla devs want to use it or not
[23:42] <cody-somerville> lol
[23:43] <cody-somerville> I want to know if there is a download for the 3.4 branch of bugzilla
[23:43] <cody-somerville> I see a download for 3.2 and 3.0
[23:43] <fta> ok, then nm, i don't know. i should not have tried to answer
[23:44] <cody-somerville> fta, I wouldn't say that. I greatly appreciate your attempt.
[23:45] <mwhudson> woo inline commenting
[23:46] <wgrant> mwhudson: It's a bit broken, though.
[23:46] <mwhudson> is it?
[23:46] <wgrant> But the main one is fixed in devel.
[23:46] <wgrant> The comments have an empty subject, which makes emails very confusing and hard to read.
[23:46] <james_w> cody-somerville: I thought it was included in 3.4
[23:46] <wgrant> And the UI makes me sad.
[23:46] <mwhudson> ah
[23:48] <fta> hu? inline commenting? like in google codereview?
[23:48] <mwhudson> fta: probably not, adding a bug comment doesn't reload the page now
[23:49] <fta> oh, ok
[23:49] <wgrant> Google Code's inline review commenting is pretty awesome.
[23:50] <fta> yeah, i like it too.