[00:21] <cody-somerville> launchpad seems to be experiencing difficulty :/
[00:36] <jkakar> Dear Launchpad, please read my mind and only send me mail I care about.
[00:36] <exarkun> co-signed exarkun
[00:37] <exarkun> also, would it to really hard to bundle up file-attached messages like normal comments are bundled up?
[00:38] <jml> exarkun, I don't know. My guess is "no, it wouldn't be really hard"
[00:38] <wgrant> How are normal comments bundled up?
[00:38] <jml> jkakar, our initial mind-reading trials were a disaster.
[00:39] <jml> wgrant, I don't know. :)
[00:39] <wgrant> I mean, what effect does it achieve?
[00:39] <jml> I believe there's some logic in some of the event handlers for bugs.
[00:39] <wgrant> In particular, what effect does it give that attachments do not have?
[01:14] <mkanat> gmb: Everything going OK now?
[03:08] <EagleScreen> is launchpad down right now?
[03:09] <spm> nope
[03:10] <spm> EagleScreen: can you be more specific - what url are you having issues with?
[03:10] <EagleScreen> i try to file a bug report against Ubuntu
[03:12] <EagleScreen> this URL https://launchpad.net/ubuntu/+filebug
[03:12] <EagleScreen> i type the bug description and i go ahead and i obtain this.. wait
[03:13] <EagleScreen> this http://imagebin.ca/view/eoTq7Zfb.html
[03:14] <spm> EagleScreen: try using edge as a "might work better" https://edge.launchpad.net/ubuntu/+filebug
[03:19] <EagleScreen> just the same error
[03:19] <spm> dare I ask what bug description?
[03:20] <spiv> EagleScreen: those timeouts are usually caused by the search for duplicates; if you enter a shorter summary into that form it may avoid the timeout.
[03:20] <spiv> EagleScreen: you can then put the full summary in again on the next screen.
[06:49] <glen> do branches expire? i'm sure i had drizzle branch here https://code.launchpad.net/~glen666
[06:51] <beuno-on-vacatio> glen, they don't
[06:51] <mwhudson> glen: no, but they hide from listings when they're merged
[06:52] <glen> ah. thanks
[11:28] <Laibsch> why does the PPA try to build for lpia architecture when the control file looks like http://paste.debian.net/45594/ ?
[11:29] <bigjools> Laibsch: "all" will build for all the arches that PPAs support
[11:29] <Laibsch> IMHO that's a bug, then
[11:30] <Laibsch> It should build for all arches for "any"
[11:30] <Laibsch> all is arch-independent
[11:30] <Laibsch> bigjools: Are you sure about what you said?  Or is it more of a hunch?
[11:31] <bigjools> then set it to "any"!
[11:31] <Laibsch> bigjools: Do you even know the difference between any and all?
[11:31] <bigjools> any is arch-indep
[11:31] <bigjools> all means all
[11:31] <Laibsch> in the debian control file context
[11:32] <Laibsch> hm, was it me who got it backwards, then?
[11:32] <geser> bigjools-afk: are you sure? "any" is rebuild on every arch, "all" is arch-indep
[11:33] <Laibsch> yeah, I just checked myself
[11:33] <Laibsch> And bigjools-afk got it backwards
[11:33] <Laibsch> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture
[11:35] <Laibsch> * all, which indicates an architecture-independent package.
[11:35] <Laibsch> * any, which indicates a package available for building on any architecture.
[11:39] <Laibsch> geser: could it be that LP is coded with bigjools-afk's understanding of any and all?  IOW, did I hit a bug or am I doing something wrong?
[11:40] <geser> you could dig in the LP code to look it up
[11:42] <Laibsch> I doubt that ;-)
[11:42] <Laibsch> look <> understand
[11:44] <james_w> Laibsch: and the build fails with "not for this arch"?
[11:45] <p_masho> anyone can help a newbie with cvs imports ?
[11:45] <Laibsch> Not sure what it failed with, I'd have to look it up
[11:45] <Laibsch> james_w: Fact is that it failed.  And I made a new upload, stripping lpia from the arch lines in control to make sure it wasn't going to build for that arch.
[11:46] <geser> can you link your PPA please?
[11:46]  * Laibsch likes the PPA green rather than red, purely asthetics
[11:46] <Laibsch> sorry, sure
[11:46] <Laibsch> https://launchpad.net/~r0lf/+archive
[11:47] <Laibsch> openoffice package
[11:47] <Laibsch> acroread may be the same
[11:48] <Laibsch> yes, acroread builds for lpia which I think it shouldn't
[11:48] <james_w> Laibsch: do you have permission to distribute acroread?
[11:49] <james_w> openoffice .dsc has "Architecture: any"
[11:49] <james_w> so why shouldn't it start the build?
[11:53] <Laibsch> james_w: The way I read debian/copyright, the package is free to redistribute.  If it isn't, then the place I got it from is in violation, too :-P
[11:53] <wgrant> It isn't.
[11:53] <wgrant> It's not redistributable.
[11:53] <Laibsch> OK, I'll check that and remove it if necessary
[11:53] <wgrant> Unless it's very old.
[11:54] <Laibsch> the technicalities remain.  acroread should not have built for lpia
[11:54] <james_w> "+-	You may make and distribute unlimited copies of the Software, including
[11:54] <james_w> +copies for commercial distribution, as long as each copy that you make and
[11:54] <james_w> +distribute contains this Agreement, the Acrobat Reader installer, and the same
[11:54] <james_w> +copyright and other proprietary notices pertaining to this Software that appear
[11:54] <james_w> +in the Software."
[11:54] <wgrant> Laibsch: Why not?
[11:54] <james_w> so unless that is out of date it appears to be possible to redistribute the binaries
[11:55] <wgrant> james_w: Where'd you find that?
[11:55] <james_w> Laibsch: you seem to misunderstand how the system works
[11:55] <mtaylor> yikes. +linkblueprint is now not very useful on edge
[11:55] <james_w> wgrant: debian/copyright
[11:55] <wgrant> james_w: Ha ha. We all know how up-to-date that often is...
[11:55] <james_w> +ELECTRONIC END USER LICENSE AGREEMENT
[11:55] <james_w> +FOR ADOBE ACROBAT READER
[11:56]  * wgrant hunts.
[11:57] <Laibsch> james_w: where's my misunderstanding.  If there is an "any"-line in openoffice, that's a different story, then.  But acroread does not contain such a thing.
[11:57] <Laibsch> My understanding of the control file is, the PPA should not try to build it for lpia.
[11:57] <james_w> it does
[11:58] <james_w> you are wrong
[11:58] <Laibsch> it does?
[11:58] <Laibsch> contain an "any" line?
[11:58] <Laibsch> grep tells me differently
[11:58] <james_w> yes, the system could be improved, but it looks to me as though LP is doing exactly what it should
[11:58] <wgrant> See bug #43780
[11:58] <wgrant> That has some nice bits of the license.
[11:58] <james_w> Laibsch: you are looking in the wrong place
[11:58] <Laibsch> where's the right place
[11:58] <Laibsch> ?
[11:58] <james_w> Laibsch: look in the .dsc as I indicated earlier
[11:59] <wgrant> So, Launchpad does not respect a subset of architectures if they are listed in the control file.
[11:59] <Laibsch> james_w: your earlier comment was about OOo
[11:59] <wgrant> It will respect 'all', but 'i386 amd64 foo64' is treated just like 'any'.
[11:59] <james_w> it should not start the actual build
[11:59] <Laibsch> james_w: that's not what I'm talking about
[11:59] <james_w> but dispatching it is well within its rights
[11:59] <wgrant> Right.
[11:59] <wgrant> sbuild will say no.
[12:00] <Laibsch> I'm confused now
[12:00] <Laibsch> How do I prevent the PPA from building lpia, then?
[12:00] <james_w> Laibsch: and you couldn't apply a mental sed of s/OOo/acroread/ and check that too?
[12:00] <wgrant> You cannot stop it from trying.
[12:01] <james_w> P-a-s applies to PPAs too?
[12:01] <wgrant> The way it's stopped in the primary archive is Packages-architecture-specific.
[12:01] <Laibsch> james_w: what's a mental sd?
[12:01] <Laibsch> sed
[12:01] <wgrant> But P-a-s explicitly doesn't apply to PPAs.
[12:01] <wgrant> That's quite deliberate.
[12:01] <james_w> Laibsch: I mean I told you why it was happening for OOo, it's not too much of stretch to see if the same explanation applies to acrororead
[12:02] <Laibsch> james_w: Again: no "any" line in there, OK?
[12:02] <Laibsch> It's nice pointing back to your earlier comment
[12:02] <james_w> Laibsch: my eyes tell me different
[12:03] <wgrant> Architecture: any
[12:03] <james_w> "https://edge.launchpad.net/~r0lf/+archive/ppa/+files/acroread_9.1.3-0.2~rolf1.dsc -> Architecture: any"
[12:03] <wgrant> Straight from the acroread dsc.
[12:03] <Laibsch> james_w: then you're looking at the wrong thing
[12:03] <james_w> ???
[12:03] <Laibsch> check the pastebinit link if you don't believe me
[12:03] <james_w> Laibsch: no, you are looking at the wrong thing
[12:03] <wgrant> I believe the files that Launchpad has are the files that Launchpad has.
[12:03] <wgrant> Not the pastebin.
[12:03] <james_w> you have a too-simplistic view of how this works
[12:03] <james_w> while your view is idealised, the real system doesn't work how you expect for various reasons
[12:07] <geser> Laibsch: the .dsc file contains Arch: any while your debian/control only Arch: i386 amd for some packages
[12:07] <geser> the build queue uses the .dsc file (if I'm correct)
[12:09] <wgrant> geser: You are correct.
[12:13] <Laibsch> james_w: I think an easier expression than "your view is idealised" or what not is just plain and simple "no matter what you do the PPA will build for all three arches"
[12:13] <Laibsch> I think it would be nice if that changed
[12:14] <james_w> I can't find a license agreement in either the .deb or .tar.bz2 on ftp.adobe.com, and the license stated in debian/copyright probably makes the .deb un-redistributable, as the bug wgrant pointed to indicates
[12:14] <james_w> so I think you should not have it in your PPA
[12:14] <wgrant> james_w: The binaries and the source, I suspect.
[12:15] <james_w> wgrant: sorry?
[12:15] <wgrant> james_w: You said just the .deb. I presume you mean the source package as well.
[12:15] <james_w> Laibsch: I'm not sure what happens if you upload a .dsc with "Architecture: i386 amd64"
[12:15] <james_w> but yes, I agree
[12:15] <james_w> wgrant: ah, true
[12:19] <Laibsch> james_w: well, I may be able to hand-tweak things and eventually get a result.  But this is just the dsc that debuild produced from the information in the debian dir.  It may be that debuild/dpkg-buildpackage is wrong to put "any".  Then again, it may not be.  I'm too lazy now to find out ;-)
[13:15] <hexa-> hi
[13:15] <hexa-> is there a way i can stop crawlers to index my name on launchpad?
[13:16] <hexa-> that is really something i don't like to happen
[13:16] <henninge_> henninge: don't use your real name
[13:16] <henninge_> hexa-: ^
[13:16] <henninge_> hexa-: it's just the name, though.
[13:17] <hexa-> its just a privacy issue with me
[13:17] <henninge_> hexa-: E-Mail addersses are not available to anonymous users which spiders are.
[13:17] <hexa-> yeah well i blocked email adresses anyhow
[13:17] <henninge_> hexa-: Do you consider your name to be private information?
[13:17] <hexa-> yes, I do
[13:18] <hexa-> it shows for example my affiliations
[13:18] <henninge_> Your *real* name does?
[13:18] <henninge_> Or which name are we talking about?
[13:18] <hexa-> yes
[13:18] <hexa-> realname
[13:18] <henninge_> Bernd das Brot? ;-)
[13:18] <hexa-> i changed my display name now, though, this should do the trick, thanks so far :)
[13:18] <hexa-> no :P
[13:18] <henninge_> what's the affiliation ?
[13:19] <hexa-> well, someone beeing related to s.th.
[13:19] <henninge_> hexa-: kein Problem ...
[13:19] <henninge_> oh, your family reations
[13:19] <hexa-> ;)
[13:19] <hexa-> einfach verbindungen
[13:19] <hexa-> jemand sucht meinen namen bei google und weiss wo ich rumhänge, was ich tue usw
[13:19] <hexa-> das muss einfach nicht sein
[13:20] <henninge_> Da gibt es nur eins: nicht den wirklichen Namen benutzen.
[13:20] <hexa-> ja, habe ich jetzt getan :)
[13:21] <henninge_> Don't be surprised, this is still an English language channel! ;-)
[13:21] <henninge_> everybody!
[13:21] <hexa-> :P
[13:21] <hexa-> just took the opportunity :
[13:23] <henninge_> np, this was meant for everybody else but I forgot the "everybody" in the sentence ...
[14:31] <jamone1313> I have a clean Ubuntu install, I've followed the guide exactly and in the "make run" stage I get "psycopg2.OperationalError: FATAL:  Ident authentication failed for user "launchpad_main""
[14:31] <jamone1313> after that it quits, I've tried doing a "make clean.... make run" but same deal
[14:33] <MTeck> jamone1313: #launchpad-dev
[15:56] <rickspencer3> hi guys
[15:57] <rickspencer3> I'm getting an error on one of my apps that uses python-launchpadlib
[15:57] <rickspencer3> I'm betting that you all know what exactly is going on, but I can't find a reference to it :(
[15:57]  * rickspencer3 is let down by Google
[15:57] <gary_poster> rickspencer3: at least one of us might know exactly what is going on. :-) what's up.
[15:57] <rickspencer3>   File "/home/rick/bug-zapper/python/LaunchpadUtils.py", line 22, in <module>
[15:57] <rickspencer3>     from launchpadlib._utils.uri import URI
[15:57] <rickspencer3> ImportError: No module named _utils.uri
[15:57] <rickspencer3> looks like modules got changes around or something, and I'm not smart enough to figure it out :)
[15:58] <gary_poster> rickspencer3: see lazr.uri
[15:58] <gary_poster> rickspencer3: (getting link for you; it is packaged for karmic)
[15:59] <rickspencer3> gary_poster, thanks
[15:59] <rickspencer3> it looks like it's installed
[15:59] <rickspencer3> i A python-lazr-restfulclient                                           - client for lazr.restful-based web services
[15:59] <rickspencer3> i A python-lazr-uri                                                     - library for parsing, manipulating, and generating URIs
[15:59] <gary_poster> rickspencer3: oh ok awesome.
[15:59] <gary_poster> yeah that's the one
[15:59] <gary_poster> lazr.uri.URI might work...
[15:59] <rickspencer3> so this functionality was removed from launchpad?
[16:00] <rickspencer3> and I just need to port the code to lazr?
[16:00] <rickspencer3> that seems within my skills and abilities ;)
[16:01] <rickspencer3> gary_poster, wait
[16:01] <gary_poster> rickspencer3: well, removed from launchpad to be usable separately.  launchpad still uses it, but as a distribution.  But yeah, just use the lazr version :-) .  We've not taken the time to do the super simple job to make this pretty, but here are some docs: http://pypi.python.org/pypi/lazr.uri/1.0.2
[16:01] <rickspencer3> thanks gary_poster
[16:02] <rickspencer3> your help is much appreciated
[16:02] <gary_poster> np!
[16:02] <gary_poster> rickspencer3: quickly looks very cool btw
[16:03] <rickspencer3> thanks gary_poster
[16:03] <rickspencer3> it's fun to work on
[16:04] <rickspencer3> being able to easily use my PPA is so great
[16:04] <rickspencer3> I never quite got a project to build in my PPA before I started using quickly
[16:05] <rickspencer3> so I'm hopeful that we'll see a few more apps on Launchpad
[16:05] <gary_poster> awesome. :-)
[16:05] <gary_poster> I like the deb integration stuff, among the other cool bits, yeah
[16:05] <rickspencer3> didrocks is truly a rock star :)
[17:44] <jkakar> I'm trying 'bzr branch lp:~sidnei/lazr-js/jstestdriver-testing' (private branch for some reason) and getting: bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/lazr-js/toolchain-1.6/".
[17:44] <jkakar> I guess toolchain-1.6 was the stacking-on branch and that it's now gone.  Anyway, how do I get the branch I want?
[18:17] <gary-lunch> jkakar: good question.  abentley?
[18:20] <abentley> jkakar, gary_poster: Confirmed, that's the stacked-on branch.  If there is another branch with all the revisions from bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/lazr-js/toolchain-1.6/ you can change the stacked on location to that.
[18:21] <abentley> jkakar: And then you can branch it.
[18:21] <gary_poster> Thank you abentley. jkakar: I don't know what the desired stacked-on branch is.  Would you like me to guess at some people for answering that question, or do you know?
[18:21] <jkakar> abentley: Okay.  I have no idea what toolchain-1.6 is or was... hrm.  If I can't sort that out is the branch effectively unusable?
[18:22] <jkakar> gary_poster: Well, I'll chat up sidnei about it since it's his branch.  He'll probably know what he based it on.
[18:22] <gary_poster> jkakar: +1 :-)
[18:22] <abentley> jkakar: Possibly, but you can always try stacking on trunk.  Maybe the branch was merged into trunk.
[18:23] <jkakar> gary_poster, abentley: Thanks!
[18:23] <gary_poster> np :-)
[18:49] <mac_v>  hi... a few ayatana bugs have been lost in a black hole :( , this was due to recent naming change of ayatana > the ayatana project... bugs which existed in ayatana alone are now inaccessible , any way we could recover them? , the bugs were invalidated to facilitate the project to be closed , example of error > error ID  OOPS-1342F1736
[18:50] <gary_poster> mac_v: hm, I'm afraid I have no clue, but I'll ask around.  deryck, do you have any ideas?
[18:52] <mac_v> i tried to access some bugs using the .staging. site , and tried to just change the project from ayatana to papercuts >it gives this error > Not Found Object: , name: u'dead-ayatana'
[18:54] <gary_poster> intellectronica: ayt?
[18:54] <deryck> gary_poster, sorry phone
[18:54]  * deryck looks at scrollback
[18:54] <gary_poster> deryck: np, thanks
[18:55] <gary_poster> mac_v: I think our best hope is waiting for deryck.  Sorry I can't help you more.
[18:56] <mac_v> gary_poster: thanks :) , no probs i'll wait
[18:56] <deryck> gary_poster, mac_v -- yes, just looking at the oops.
[18:56] <gary_poster> cool :-)
[18:56] <deryck> I think I need more context, let me ping some others, and will reply back shortly.
[18:58] <mac_v>  the thing is , bugs which existed in ayatana alone , are now *not* accessible , since it points to DEAD-ayatana ,  since the "ayatana" was closed and started again as the "The Ayatana project"
[18:58] <mac_v> example >bug #387828
[18:58] <mac_v> bug #387828
[19:01] <mac_v> this happens to bugs reported first in ayatana [actually changed to ayatana from hundred papercuts where it was first reported]
[19:01] <deryck> mac_v, ah, I think I'm understanding now.  So you need to move all the invalid ayatana bug tasks to papercuts?  or just a select few?
[19:02] <mac_v> deryck: yup, moving all the invalid ayatana back to papercuts will do
[19:03] <mac_v> deryck: there were just 17 bugs , which were invalidated , i some how managed to change this > bug #387828
[19:03] <mac_v> oops wrong bug!
[19:04] <mac_v> https://bugs.staging.launchpad.net/hundredpapercuts/+bug/387828
[19:04] <mac_v> huh! ok the right one ;p
[19:06] <mac_v> https://bugs.launchpad.net/dead-ayatana/+bug/387828
[19:07] <mac_v> ah! sorry!
[19:07] <mac_v> i keep pasting the same bug!
[19:07] <mac_v> https://bugs.launchpad.net/bugs/387573
[19:08] <deryck> mac_v, I just reassigned one myself no problem.
[19:08] <deryck> mac_v, bug 387828
[19:08] <deryck> mmmm, I thought I did.
[19:09] <mac_v> deryck: hehe , the bug in the browser shows correct , ubottu is wrong
[19:09] <deryck> mac_v, is what I just did the end result you want?
[19:09] <mac_v> yes
[19:10] <mac_v> bug 387828
[19:10] <mac_v> hmm!
[19:10] <deryck> mac_v, I clicked the edit icon to change it.  Let me try another via the form that is revealed.
[19:10] <mac_v> deryck: couldnt the ubottu be corrected too? it would be easier to discuss
[19:11] <mac_v> ah i tried that earlier  but for me it gives this error > Not Found Object: , name: u'dead-ayatana'
[19:11] <deryck> mac_v, not sure.  I don't really know anything about ubottu.
[19:12] <mac_v> deryck: ok, no probs , do you want the list of the bugs which need this change? or do you have them
[19:14] <intellectronica> deryck, mac_v: i think it may be hidden depending on permissions
[19:14] <deryck> mac_v, I don't have them.
[19:15] <mac_v> deryck: ok ,just 16 more :)  i'll paste them one by one here
[19:15] <deryck> mac_v, can you change one yourself via the edit icon.  or that is what fails for you?
[19:15] <mac_v> deryck: no... it just gives me oopses! :( https://bugs.launchpad.net/dead-ayatana/+bug/387573
[19:16] <mac_v> error ID  OOPS-1342D2057 , was for the above link ^
[19:16] <deryck> mac_v, ok, I can do them.  Can you send me an email with the 16 bugs left?
[19:16] <mac_v> intellectronica: i think you are correct , but this whole name change has a few users really pissed
[19:17] <mac_v> email id?
[19:17] <mac_v> deryck: ^
[19:17] <deryck> mac_v, deryck dot hodge @ the company I work for working on launchpad dot com :)
[19:18] <mac_v> ;p
[19:18] <intellectronica> mac_v: can you see https://bugs.edge.launchpad.net/dead-ayatana/+bugs?search=Search&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress&field.status=Fix+Committed&field.status=Fix+Released&field.status=Invalid&field.status=Won%27t+Fix&field.omit_dupes.used=
[19:18] <intellectronica> and if yes, are these the 16 bugs you need moving?
[19:18] <encbladexp> how can i remove some SVN Import from Launchpad?
[19:18] <mac_v> intellectronica: i get 404  , page not found
[19:19] <deryck> ah, so that's the issue then.  it's permission, no? intellectronica
[19:19] <intellectronica> mac_v, deryck: right, so it is a permissions thing
[19:19] <deryck> right
[19:19] <mac_v> deryck: lmao "the company I work for working on launchpad dot com "
[19:19] <intellectronica> and since the list shows exactly 16 bugs, my guess is these are the 16 bugs you need moved :)
[19:19] <deryck> intellectronica, mac_v -- yeah, I can do it from that list. no email needed
[19:19] <mac_v> deryck: could you move them? or do i have to mail you?
[19:20] <deryck> mac_v, I can.
[19:20] <mac_v> hehe , ok
[19:20] <intellectronica> deryck: should be very easy to do with launchpadlib
[19:20] <mac_v> deryck: \o/ thanks , pls ping me when it done :) it needs to be assigned
[19:21] <deryck> intellectronica, yeah, that's what I was going to use.
[19:24] <mac_v> how were you guys able to remove a project? for example i had used "also affects" for the alt_tab compiz bug , so there were 3 projects ayatana,papercuts,compiz , but now it have only 2... is it permissions again? ;p
[19:25] <mac_v> *only has
[19:26] <kiko> mac_v, I think it's because ayatana went away
[19:26] <mac_v> kiko: deryck did something now ;)
[19:27] <mac_v> kiko: ayatana issue is the reason why i cant access it
[19:27] <kiko> oh?
[19:28] <mac_v> kiko: :( , this is a long story , pls scroll back :( sorry
[19:30] <kiko> deryck, what's the summary of the problem? :)
[19:32] <deryck> kiko, so mac_v wants to move the invalid dead-ayatana bugs to hundredpapercuts.  mac_v doesn't have permission to see the dead project so can't.
[19:32] <deryck> kiko, I was working up a script to do so.
[19:35] <kiko> deryck, well.. I think that most of the ayatana bugs already had hundredpapercuts tasks
[19:35] <kiko> so I doubt that will work
[19:35] <kiko> what you could do is just kill those bugtasks
[19:36] <mac_v> kiko: no , the bugs were actually mostly reassigned from papercuts to ayatana  , maybe one had papercuts too
[19:38] <deryck> kiko, yeah, a quick glance says most of them don't have paper cuts tasks.
[19:40] <kiko> deryck, I can make the project come back to life
[19:41] <mac_v> kiko: someone actually doesnt want that ;) , they didnt like just "ayatana"
[19:43] <mac_v> deryck: > is the one with both https://bugs.launchpad.net/bugs/388121 , so you can just remove ayatana
[19:43] <mac_v> this is*
[19:47] <kiko> I was the one that actually disabled that project
[19:47] <kiko> so I could temporarily reenable it
[19:48] <mac_v> kiko: the "dead-" prefix is due to the project being closed , right?
[19:48] <kiko> I added it
[19:48] <mac_v> oh
[19:58] <deryck> mac_v, kiko -- I'm just moving them by hand; it's easier to see which don't have hundredpapercuts and which aren't dups, and just use the ajax speed.
[19:59] <mac_v> thanks :)
[20:01] <deryck> mac_v, done.  There are some dead-ayatana tasks left where there was already a papercuts task, but you can find them all assigned to papercuts now.
[20:04]  * mac_v checking 
[20:37] <mac_v> kiko: could you remove the "Ayatana" project , from these bugs > Bug #388121 , Bug #391533 , Bug #393599 , Bug #387830
[20:37] <mac_v> pls":)
[20:37] <kiko> mac_v, I can't but deryck can probably delete it
[20:37] <kiko> via a DB query
[20:37] <mac_v> deryck seems offline :(
[20:38] <mac_v> intellectronica: could you do that ?^
[20:40] <kiko> mac_v, file a question on answers.launchpad.net/launchpad
[20:40] <kiko> the OSAs know how to do this
[20:41]  * mac_v hm... so much confusion over these permissions :(
[20:41] <kiko> mac_v, I still don't understand what problem you are running into
[20:41] <mac_v> kiko: just a sec , let me concise it :)
[20:44] <kiko> is the problem that you can't see those bugs?
[20:44] <kiko> I can temporarily reenable it
[20:44] <mac_v> that has been solved
[20:45] <kiko> so what's the catch?
[20:45] <mac_v> kiko: several bugs were reported in papercuts first , they seemed good bugs , but too big to be papercuts , so the papercut task was changed to ayatana, now ayatana is closed , since the first reported task is the url that firefox opens the bug with , now they were not accessible
[20:45] <mac_v> kiko: now that has been fixed by deryck
[20:46] <kiko> gotcha
[20:46] <mac_v> kiko: but a few of the bugs still have the name "Ayatana" , only those 4 , so they want it clean ;)
[20:46] <mac_v> so that ayatana is not mentioned
[20:47] <kiko> we'd need to move them to other products
[20:47] <kiko> but which ones?
[20:47] <mac_v> kiko: we can change them to null ;) , but i was wondering why not just remove the task
[20:48] <mac_v> oh other tasks , thats a good idea :)
[20:49] <mac_v> kiko: could you change those 4 to "Ubuntu" ?
[20:49] <kiko> we can't
[20:49] <kiko> I wish we could
[20:49] <kiko> but we can't
[20:49] <mac_v> hmm :(
[20:49] <kiko> can we affect another upstream?
[20:50] <mac_v> i dont think there is any upstream equivalent , it would be just a dead invalid it that too
[21:05] <mac_v> kiko: any chance intellectronica / deryck or anyone else with the permissions might come back in a couple of hrs... i dont mind waiting...
[21:05] <mac_v> ?
[21:13] <discHead> Hey all, this may be a dumb question, but I'll ask anyway.  I create a branch, propose it for a merge, and the maintainer merges it.  If I want to do more work in the same vein, should I not touch that branch again and make a new one?  Or is it safe to make new changes on that branch and make additional merge proposals, without things getting messy in Launchpad?
[21:14] <thumper> yes you can do this
[21:14] <thumper> there is a limit of one active proposal per branch
[21:14] <thumper> but a merged one isn't considered active
[21:15] <discHead> Oh, okay.  So after it's been accepted and merged, then I do more work on it and propose another merge, it shows up the same as would a new branch with a merge proposal.
[21:16] <mac_v> thumper: hi... do you have permissions to remove a project from a bug?
[21:16] <mac_v> or who are the members i need to wait for to do that?
[21:19] <thumper> discHead: yes
[21:19] <thumper> mac_v: I don't think a project can be removed from a bug once added :(
[21:19] <encbladexp> can anybody remove https://code.launchpad.net/~vcs-imports/pyneighborhood/trunk and https://code.launchpad.net/~vcs-imports/pyneighborhood/0.4 from code.launchpad.net? thx
[21:19] <thumper> encbladexp: perhaps I could
[21:19]  * thumper looks
[21:19] <encbladexp> :-D
[21:20]  * encbladexp is migrating some Things from "Good old SVN" to Bazaar and Mercurial
[21:20] <discHead> Thanks, thumper, that's been bugging me, so I appreciate the help
[21:20] <thumper> encbladexp: the trunk branch is the development focus, so I can't remove that on
[21:21] <thumper> discHead: np
[21:21] <thumper> encbladexp: if you choose a different branch as trunk, I can delete the old import
[21:21] <encbladexp> https://code.launchpad.net/~pyneigborhood/pyneighborhood/devel this is the new "Development Focus"
[21:21] <thumper> encbladexp: but is isn't linked to the series
[21:22] <encbladexp> mom, i will do that...
[21:25] <encbladexp> thumper, done https://code.launchpad.net/~vcs-imports/pyneighborhood/trunk can now removed
[21:39] <thumper> encbladexp: done
[21:41] <encbladexp> thx
[21:41] <encbladexp> hmm, how can i branch Revision (e.g.) 321 vom the devel branch to the 0.5 branch using bzr?
[21:44] <kiko> mac_v, there's no permissions issue. you need to ask a question; an OSA needs to process it.
[21:45] <mac_v> oh...
[21:46] <zobi1> I requested a download of translation files about an hour ago. I haven't received any emails yet. Is this a manual process? How long should I expect to wait?
[21:47] <kiko> zobi1, I think the translation import queue is kinda stacked this week due to a bug which we fixed earlier
[21:47] <kiko> danilos has the details but I think he's out already
[21:49] <mac_v> kiko: so how soon can we expect the question to be answered? [i know stupid question] , if it will take longer than 1-2 days , would trying to catch deryck tomorrow be quicker?
[21:50] <zobi1> kiko: can I email danilos or is there someone who could give me an estimate? Is it in the hours or days range?
[21:50] <kiko> mac_v, no, deryck can't do this. only an OSA can.
[21:50] <mac_v> oh :(
[21:50] <kiko> zobi1, should be in the hours range
[21:50] <kiko> if we're lucky
[21:50]  * mac_v wonders who these elusive OSA are ;p
[21:51]  * mac_v filing question
[23:32] <andrewkk> What is https://launchpad.net/~junkmongers and why is it subscribed to a bug in my project?
[23:40] <wgrant> andrewkk: The bug probably has a task for the Obsolete Junk project.
[23:42] <andrewkk> wgrant: Ah-ha, I see. Thanks.