[00:00] <MTecknology> thanks :)
[00:00] <mthaddon> np
[00:04] <MTecknology> mthaddon: so - how busy is the life of a losa?
[00:05] <mthaddon> not sure how you'd measure that, but definitely pretty damn busy
[00:05] <mthaddon> being able to do five things at once is a plus, put it that way
[00:07] <MTecknology> I've been working on moving my servers to different locations entirely and different services 22:00 - 05:30 last night and 11:00 - 18:00 today
[00:07] <MTecknology> still working on it - and doing homework :P
[00:11] <mthaddon> sounds like... fun
[00:11] <MTecknology> yup...
[00:12] <MTecknology> moving my mail server to zimbra, 3 other servers to one linode
[00:13] <MTecknology> from zimbra to gmail *
[00:16] <Marco> When the proposed branch for a merge proposal is committed to, the diffs on the merge proposal page don't update
[00:16] <Marco> is it possible to force them to update?
[00:23] <mwhudson> Marco: no, not yet
[01:01] <lifeless> barry: ping
[01:01] <lifeless> barry: lp lists break gpg signatures, how do I configure them not to be hostile?
[01:12] <lifeless> interesting, its inconsistent. I think there is a mailman bug rather than bad settings
[01:13] <spm> lifeless: or MUA bug? I've been somewhat working with barry to try and identify a fail with his signing of messages - no mailman middleman required
[01:14] <lifeless> spm: possibly, testing
[01:18] <lifeless> spm: no, not MUA failure
[01:18] <spm> cool. something else then. yay.
[01:18] <lifeless> spm: if I forward the same mail to me@canonical.com, it comes through signed validly
[01:18] <spm> lifeless: how'd you score me@c.c!!!!!?!?!?! :-P
[01:20] <lifeless> bug 383784
[01:23] <spm> lifeless: (if you aren't already) it's a bit of a brute force triage; maybe doing a cmd line gpg verify against multiple list maildir's? each and every post that's signed. that'll give a list of emails to examine for fail equivalence. ???
[01:30] <lifeless> I have a hunch
[01:30] <lifeless> I suspect its a mailman fail on a signed forward signed message
[01:32] <lifeless> bbs
[01:54] <poolie> hello all
[01:55] <lifeless> ola!
[02:04] <lifeless> barry: bug 383784 should have enough data to debug now
[02:15] <duanedesign> bac: At a ,eeting of the Community Council it was decided that the inactive "New User Network" would be replaced by the "Ubuntu Beginners Team"
[02:15] <duanedesign> s/,eeting/meeting
[02:16] <duanedesign> The NUN Launchpad page needs to be deactivated
[02:17] <duanedesign> Can that request be taken care of here or does this need to go to Launchpad Answers
[02:18] <spm> duanedesign: it's in progress as we speak! :-) nhandler has put the requests thru, and I'm personally verifying the changes work on staging - have to do some minor sql hackery to do the migration.
[02:18] <spm> duanedesign: tho... perhaps not the deactivation bit - but that's very easy.
[02:18] <duanedesign> oh well thank you.
[02:18] <duanedesign> :)
[02:19] <spm> duanedesign: can you pls put a request thru for the above, and ping me when it's up? I'll take it from tehre.
[02:20] <duanedesign> absolutely
[02:38] <vorian> any eta on a chrootwait errors fix for ppa's?
[02:40] <duanedesign> spm: Open  Question #73299  Thank you for your help on this matter.
[02:40] <wgrant> vorian: That's an #ubuntu-devel issue.
[02:41] <vorian> wgrant: thanks
[05:27] <hyperair> hello. there's an issue with the karmic buildds, due to a recent upgrade in coreutils (it now ships mktemp) which requires mktemp to be removed
[05:27] <hyperair> at least, for PPAs.
[05:28] <hyperair> http://launchpadlibrarian.net/27513396/buildlog_ubuntu-karmic-i386.banshee_1.5.0~git20090604.r1.c6cf6a1-0ubuntu1_CHROOTWAIT.txt.gz
[05:28] <hyperair> this is an example.
[06:02] <tc-rucho> hi. Is launchpad going to have a per-project integrated wiki soon?
[06:15] <wgrant> hyperair: #ubuntu-devel is appropriate for that.
[06:23] <hyperair> wgrant: you mean the guys at #ubuntu-devel are in charge of the buildds?
[06:23] <wgrant> hyperair: It's the archive that is broken, not the buildd.s
[06:23] <wgrant> The buildds just happen to need an unbroken archive to work.
[06:24] <hyperair> i don't think the archive's broken. it's just that coreutils contains mktemp now, and it's no longer needed
[06:24] <hyperair> but the buildds refuse to accept that.
[06:24] <wgrant> It breaks all upgrades.
[06:24] <wgrant> Not just buildds.
[06:25] <hyperair> yes it does, but if you allow it to remove mktemp, the upgrade is essentially unbroken
[06:25] <hyperair> it's a case of aptitude's stubbornness
[06:26] <wgrant> No... it's a case of the new coreutils being broken.
[06:26] <wgrant> It's always expected that it won't automatically remove an Essential package.
[06:26] <wgrant> Anyway, #launchpad people would have less control over the buildd chroots than #ubuntu-devel.
[06:26] <hyperair> i see
[08:51] <cavedon> hi all, is karmic PPA chroot broken?
[08:53] <cavedon> (looks like karmic chroots cannot be build right now, in general, because of some mktemp/coreutils depency conflict)
[08:55] <wgrant> cavedon: Karmic is broken in general.
[08:56] <wgrant> cavedon: Waiting for an Ubuntu buildd admin to sort things out.
[08:56] <cavedon> wgrant: ic, tnx!
[08:56] <wgrant> cavedon: The builds should all be retried when things are fixed.
[11:17] <pitti> hello
[11:17] <pitti> where can I request https://code.edge.launchpad.net/~vcs-imports/hal/main to be deleted?
[11:17] <pitti> (it's an ancient abandoned CVS import)
[11:18] <pitti> I'd like to request a git import, but I would like to use the lp:hal for that
[11:18] <oldman_> anyone free to approve some translation file imports that are sitting in needs review?
[11:19] <henninge> oldman_: which?
[11:19] <jtv> oldman_: got a URL for the project?
[11:19] <henninge> ;-)
[11:19] <oldman_> https://translations.launchpad.net/gtk-recordmydesktop/+imports
[11:19] <oldman_> thanks :)
[11:20] <popey> :)
[11:20] <oldman_> heh
[11:20] <popey> hilight on rmd working well there ;)
[11:20] <oldman_> lol
[11:21] <jtv> oldman_: are you the author?
[11:21] <oldman_> no
[11:21] <oldman_> they are ~vcs-imports imports
[11:21] <oldman_> they will be pushed back upstream to sourceforge
[11:22] <oldman_> I will be authoring the languages I know though :)
[11:22] <popey> oldman_: you going to put this in your ppa?
[11:22] <oldman_> popey: yeah i'll merge with debian/* from the repos at some point
[11:22] <popey> cool
[11:22] <oldman_> working on ./configure --enable-pulse=yes at the mo :)
[11:22] <popey> awsome
[11:23] <jtv> oldman_: okay, alternatively, what's your arrangement with the authors about translating this?  I ask because we don't want people making lots of spontaneous contributions that won't be looked at.
[11:23] <popey> http://beeroverip.org/ | oldman_
[11:24] <oldman_> jtv: current arrangement is that the changes will be pushed back upstream to the current maintainer, and also used in custom/forked releases until such point when the maintainer is able to become more active/involved again
[11:24] <jtv> oldman_: if some of the languages won't be translated in Launchpad, it's important to make sure we don't invite people to contribute to those.
[11:26] <jtv> oldman_: what we can do in that case is create a translation group and set access permissions to Restricted.
[11:26] <oldman_> changes will automatically be synced by ~vcs-imports and automatic bzr import in rosetta
[11:26] <jtv> oldman_: oh, so it goes both ways for all languages?
[11:26] <oldman_> that's the intention :)
[11:26] <jtv> oldman_: ok, hang on...
[11:26] <oldman_> though the likelihood of any upstream translation is probably quite unlikely
[11:27] <oldman_> as SF access is restricted to mailed-in patches to an currently inactive single maintainer
[11:27] <jtv> oldman_: template is approved; translations should follow automatically.
[11:27] <oldman_> last code change was >6 months ago
[11:27] <oldman_> many thanks!
[11:27] <jtv> np
[11:52] <Peng_> Random question that's probably answerred somewhere: why isn't the librarian https?
[11:52] <Peng_> (In fact, I'm pretty sure I've heard the answer, but I don't remember it.)
[11:53] <wgrant> It does both.
[11:54] <Peng_> Oh, I totally didn't know that. Cool. Why http by default, then?
[11:54] <wgrant> There's no need for security, so it's just useful for authentication. And if you want authentication, you can add the 's'. (these are just educated guesses)
[11:54] <wgrant> And HTTPS is slow.
[11:56] <Peng_> OK. It seems odd since LP's default is usually HTTPS.
[11:57] <Peng_> Well, bazaar.lp is HTTP, I guess.
[11:57] <wgrant> librarian doesn't (well, shouldn't) store any sensitive information.
[11:57] <wgrant> And there are no cookies.
[11:57] <Peng_> Yeah.
[11:58] <Peng_> So much of LP uses HTTPS because some of it needs it, and it's easier to err on the side of caution, right?
[11:58] <wgrant> Some stuff is private, and all pages need cookies to be able to show the right links.
[11:58] <wgrant> And transmitting the cookie over HTTP is unthinkably bad.
[11:59] <Peng_> :)
[11:59] <Peng_> Most websites aren't so careful with cookies. It's silly, but that's probably one of my favorite things about LP. :P
[12:00] <wgrant> Most websites aren't quite so powerful.
[12:00] <Peng_> Powerful?
[12:00] <wgrant> LP's web UI has the power to distribute packages to millions of machines very quickly.
[12:00] <Peng_> Oh, good point.
[12:02] <wgrant> Plus it controls access to quite a bit of proprietary code.
[12:18] <wgrant> bac: Can you look at bug #383887, please? A lot of people have got a lot of email, and some are responding to bugs with a lot of unnecessary comments.
[12:19]  * bac looks
[12:19] <wgrant> Actually, maybe it's fixed now.
[12:20] <wgrant> Somebody worked out the terrible UI and unsubscribed the team! Incredible.
[12:22] <wgrant> Oh, no, it's still there...
[12:22] <bac> wgrant: i don't think so.  look at https://bugs.edge.launchpad.net/launchpad/+subscribe  -- the tn team and the tunisia team are still subscribed to all lp bugs
[12:23] <wgrant> Yep.
[12:23] <wgrant> THey were subscribed to more earlier.
[12:23] <wgrant> launchpad-foundations bugs were affected, but aren't any more.
[12:25] <bac> wgrant: i can't do anything ATM.  there are no losas available until our US/East guy comes on.  i'll have him handle it then
[12:25] <wgrant> bac: That's what I suspected.
[12:25] <bac> wgrant: thanks for the heads up
[12:47] <bac> wgrant: done.  thanks again.
[12:56] <barry> lifeless: excellent, thanks.  that hits me every time i forget to toggle off msg signing
[12:59] <kirkland> can anyone tell why these imports are failing?
[12:59] <kirkland> https://code.edge.launchpad.net/~vcs-imports/qemu/qemu-kvm
[13:29] <kirkland> vcs-imports questions ... they go here, or in #bzr?
[13:30] <LarstiQ> here
[13:31] <wgrant> In the case above, I suspect #bzr is more appropriate.
[13:31] <wgrant> But in general here.
[13:31] <kirkland> wgrant: cool, thanks.
[13:34] <lifeless> barry: it looks to be a bug
[13:34] <lifeless> barry: I've attached a mail that gets corrupted by it
[13:37] <kirkland> mwhudson_: howdy, getting some errors on my vcs-import, jelmer says it's fixed in his bzr-git business and waiting on LP to pick it up
[13:38] <wgrant> I hope he's not up now.
[13:46] <det> Hi, I get an error when I attempt to copy a binary package into a project PPA, but they will import fine into my PPA. I filed a bug report awhile ago, but there has been no reply. Can somebody help me ?
[13:50] <maxb> det: I doubt anyone can help you unless you give more detail. Like what the error is, for example.
[13:50] <det> Oops!
[13:50] <det> Sorry, something just went wrong in Launchpad.
[13:50] <det> We’ve recorded what happened, and we’ll fix it as soon as possible. Apologies for the inconvenience.
[13:50] <det> (Error ID: OOPS-1252ED257)
[13:50] <det> Not very informative
[13:51] <det> Been like this for more than a week
[13:51] <bigjools> det: what is the bug number?
[13:52] <det> https://bugs.edge.launchpad.net/launchpad/+bug/381743
[13:52] <bigjools> det, thanks, I think it's a dupe of bug 381239
[13:52] <bigjools> we;re working on it
[13:52] <bigjools> I'll mark it as such
[13:53] <bigjools> and I see you're an edge user, so you'll get the fix in the next day or two
[13:53] <det> Ok, thanks.
[13:53] <bigjools> sorry for the inconvenience
[13:54] <bigjools> det, in the future, if you have PPA problems, file a bug on the Launchpad Soyuz project and it'll get looked at quicker
[13:54] <det> Ok.
[13:54] <det> If it helps at all, I was deleting some packages when it broke.
[13:54] <det> I think I even deleted one where the source was published but it was still building the binaries
[13:55] <bigjools> cprov1: does that match with your investigation into that bug so far?
[13:55] <maxb> What does that mean, exactly? It breaks if you try to copy binaries into a PPA iff that (sourcepackagename, version) tuple previously was present in that PPA?
[13:56] <det> Also, I imported 2 different versions of debhelper into the PPA at once
[13:56] <bigjools> maxb: there's a huge number of corner cases associated with copying, we obviously didn't catch them all yet
[13:56] <det> Also, it seems that when I import debhelper source now, it builds but never gets published
[13:57] <det> Thanks.
[13:57] <bigjools> right, that's another bug we're fixing, you need to copy the binaries as well
[13:58] <det> But the other bug prevents me from copying the binaries of either (boost1.35 or debhelper) :-)
[13:58] <det> I haven't tried any other packages
[13:59] <bigjools> maybe just re-upload then :)
[13:59] <det> I just copied boost1.37 with no problems
[13:59] <det> So it seems it was only packages that were already there
[14:00] <maxb> I need to get around to trying adapt my copy binaries script to do it via the api at some point - currently doing it by screenscraping :-)
[14:00] <bigjools> yes, if a version already built in that PPA before you must copy binaries
[14:00] <bigjools> maxb: yes *please*
[14:00] <bigjools> maxb: archive.syncSource() ... gogogo :)
[14:01] <det> I was refering to the copy binaries bug
[14:01] <det> it seems to only be affected by the 2 packages that were already present and failed to build
[14:01] <bigjools> right
[14:02] <maxb> Yeah, but at the time I wrote it, I wanted to delete packages too, and that's not in the API yet :-)
[14:03] <bigjools> ah well, I can fix that :)
[14:04] <barry> lifeless: thanks.  i will try to find some time to look at it, even if i'm not the guy to eventually fix it
[14:05] <maxb> Is it considered a bug that the package list (e.g https://launchpad.net/~mercurial-ppa/+archive/staging-snapshots) does not show that a previous version's binaries are still published (because the new source failed to build) ?
[14:06] <bigjools> maxb: could be, that's an interesting problem
[14:24] <javaJake> Where do I create a project group? Edge testers can do it on their own now, right?
[14:26] <wgrant> javaJake: I'm pretty sure that's still restricted to admins.
[14:26] <javaJake> OK
[14:26] <wgrant> Why would you think otherwise?
[14:27] <beuno> it still is, yes
[14:29] <javaJake> wgrant: I thought someone linked me to a page where I could do it, but it was probably about creating something else.
[14:32] <beuno> javaJake, just open a question so an admin can do it for you
[14:33] <javaJake> beuno: doing so already :)
[14:36] <bac> javaJake: please include the URLs to the projects that will be part of the project groups and give some sort of rationale for why you need it.
[14:36] <javaJake> bac: already doing that too ;)
[14:36] <javaJake> I read the FAQ on requesting a project group
[14:36] <bac> javaJake: ok, great.  just trying to short-circuit a round trip with kiko...
[14:36]  * bac should read the FAQ
[14:37] <javaJake> :)
[15:15] <kiko> bac, what's that?
[15:15] <kiko> oh, URLs :)
[15:19] <neurobuntu> is it normal to experience 2-3 hour build delays on launchpad?
[15:19] <cody-somerville> neurobuntu, no
[15:19] <wgrant> But things are by no means normal at the moment.
[15:19] <neurobuntu> wgrant, ok thanks.... that was going to be my next question
[15:20] <wgrant> Karmic is currently broken, so the builders are in manual mode while things are fixed.
[15:20] <cody-somerville> wgrant, They're in manual for all distroseries?
[15:21] <javaJake> wgrant: does that have anything to do with the fact that Upgrade Manager asks to do a partial upgrade and then stops and says things aren't quite right yet?
[15:21] <wgrant> cody-somerville: There is no selectivity, unfortunately.
[15:21] <cody-somerville> cprov, ^^
[15:21] <wgrant> cody-somerville: Being able to disable a DAS would be nice.
[15:21] <javaJake> (in Karmic)
[15:21] <wgrant> javaJake: Yes.
[15:21] <cody-somerville> bigjools, ^^
[15:21] <javaJake> OK :)
[15:21] <wgrant> Oh.
[15:21] <wgrant> Things are back now.
[15:22] <wgrant> So the backlog should clear.
[15:22] <bigjools> karmic/hppa chroots were removed
[15:24] <wgrant> Will that just mean builds queue up endlessly until the DAS, builds and BPPHs are purged, or will no new builds be created?
[15:24] <bigjools> no new builds will be created
[15:24] <wgrant> Convenient.
[15:24] <bigjools> for karmic/hppa
[15:24] <bigjools> yeah, the build creation requires chroots to be present
[15:53] <bac> kiko:  i know how picky you are...
[15:54] <kiko> bac, :)
[16:06]  * bac out for a bit
[17:10] <neurobuntu> are there anyplans to introduce paid account for launchpad, paid accounts might have features like: more then 1gb of storage, domain name re-writting etc..
[17:12] <bac> neurobuntu: commercial projects can currently use launchpad.  we don't offer FOSS projects more stuff for pay, though.
[17:14] <neurobuntu> bac, i'm currently no where near it but what happens when someone hits the 1gb limit?
[17:14] <neurobuntu> do they have to create another account?
[17:19] <cody-somerville> neurobuntu|away, no
[17:20] <cody-somerville> neurobuntu|away, they can get the quota upped
[18:17] <neurobuntu> are newly uploaded packages not being accepted by launchpad right now?
[18:35] <rickspencer3> hey all
[18:35] <rickspencer3> what is the best way to get the description for a bug from a bug task (in launchpadlib)?
[18:35] <rickspencer3> I see the bug_task has a bug_link property, but not sure how to use the bug_link to get the description
[18:40] <james_w> rickspencer3: bug_task.bug.description should do it
[18:41] <rickspencer3> james_w: makes sense to me, but I got
[18:41] <rickspencer3>   File "/home/rick/pm-dashboard/TriageBugsPage.py", line 64, in get_package_bugs_complete
[18:41] <rickspencer3>     print b.bug_link.description
[18:41] <rickspencer3> AttributeError: 'unicode' object has no attribute 'description'
[18:41] <james_w> ah
[18:41] <james_w> you need b.bug.description
[18:41] <james_w> b.bug_link is the string containing the URL of the bug object
[18:42] <james_w> magic makes b.bug be the actual object
[18:42] <rickspencer3> sorry to be a dolt
[18:42] <rickspencer3> it wasn't clear from the api docs that there is a "bug" attribute
[18:42] <rickspencer3> :(
[18:42] <james_w> np, the documentation needs to be improved in my opinion
[18:42] <james_w> or rather, python docs should be generated that know about this magic
[18:43] <rickspencer3> so that worked perfectly
[18:43] <rickspencer3> thanks!
[18:43] <james_w> whenever you see something_link you can use "something" to get the object
[18:43] <james_w> when you see something_collection you can use "something" to get a list-like thing containing all the objects
[18:44] <rickspencer3> cool, good to know
[18:44] <rickspencer3> I assumed that the "_link" convention was to save resources
[18:44] <rickspencer3> so that you had to make a separate call to the server to get the next layer of info
[18:45] <james_w> it is I believe
[18:45] <james_w> however, the launchpadlib implementation will do this in the background when you access the attribute, making the API much more pleasant to use
[18:46] <james_w> it can lead to you making a lot more requests that you realise though, so it's good to check your usage where that would be important
[19:25] <maxb> Gah, the ubuntu-mozilla-daily&chromium-daily PPAs are monopolizing the builders
[19:28] <SamB> maybe they should be demoted to weekly ;-)
[19:40] <maxb> Or at least not both happen simultaneously
[19:45] <maxb> The official distro buildds seem suspiciously idle. Is something broken?
[20:21] <neurobuntu> is anybody else having problems with launchpad accepting recently uploaded package?
[20:22] <neurobuntu> like uploading packages and not hearing anything form launchpad
[20:24] <LarstiQ> neurobuntu: there can be various causes for that
[20:25] <LarstiQ> neurobuntu: often either not uploading to where you think you did, or reuploading an already uploaded orig.tar.gz
[20:25] <neurobuntu> LarstiQ, like problems on my end?
[20:25] <LarstiQ> neurobuntu: yes
[20:25] <kiko> neurobuntu, yes.
[20:25] <kiko> if you don't get any email, it's because your packages aren't signed properly
[20:25] <kiko> or being sent to the wrong address
[20:25] <LarstiQ> oh, or that
[20:26] <neurobuntu> LarstiQ, so i've been uploading packages with version numbers bigger then the ones already on launchpad but the version number stays the same on lp
[20:26] <LarstiQ> neurobuntu: and didn't get any mail, right?
[20:27] <LarstiQ> neurobuntu: has only the debian version changed, or also the upstream version?
[20:27] <neurobuntu> just the debian version
[20:28] <LarstiQ> neurobuntu: how did the .changes file get produced?
[20:28] <neurobuntu> dpkg-buildpackage -S -k<keyID>
[20:28] <neurobuntu> i tried using debuild -k<keyID> but my packages were'nt getting signed
[20:30] <neurobuntu> err... debuild -S -k<keyId>
[20:31] <LarstiQ> neurobuntu: and the .changes file is in fact signed by the key associated with your account on lp that has access to the ppa?
[20:31] <neurobuntu> yes
[20:32] <LarstiQ> neurobuntu: where did you dput it to?
[20:33] <neurobuntu> when I run dput <ppa-name> <file>.changes a .upload file is generated and I'm told that the files were uploaded succesfully
[20:33] <neurobuntu> http://paste2.org/p/249474
[20:34] <neurobuntu> I was uploading fine last night and this morning then launchpad was having problems (builds were being held) and every package I've tried to upload since then hasn't been registered by the site
[20:34] <LarstiQ> neurobuntu: which suite, karmic?
[20:34] <neurobuntu> Jaunty
[20:35] <LarstiQ> neurobuntu: ok, that should be good. I'll assume soma-testing is properly defined too.
[20:35] <neurobuntu> yes
[20:35] <LarstiQ> neurobuntu: in that case, we've run through all common mistakes, I don't know what's up
[20:36] <neurobuntu> i haven't touched my keys or my ~/.dput.cf in a few days and like I said it was all working up until launchpad wasn't building this morning
[20:36] <LarstiQ> right
[20:36] <LarstiQ> possibly stuck in a queue?
[20:36]  * LarstiQ looks at one of the lp people
[20:39] <neurobuntu> LarstiQ, i was guessing that could be the case and wanted to see if other people are having the same problems
[20:43]  * LarstiQ nods
[20:43] <LarstiQ> neurobuntu: as a user, I can't really help you further.
[20:44] <LarstiQ> but had to try, you're the first one where there isn't some point you go "aha!" and it's fixed ;)
[20:44] <neurobuntu> LarstiQ, thanks for your help its much appreciated
[20:49] <Flimm1> I'm having trouble understanding the differences between project series, and milestones
[20:50] <Flimm1> What's the difference between linking a bug to a milestone, and linking a bug to a series?
[20:50] <Flimm1> If I have a as-of-yet unreleased milestone, should I link in to the "trunk" series or to a "version number" series?
[20:58] <javaJake> Flimm1: series is simply a branch of development for that specific version
[20:58] <javaJake> Flimm1: milestone is simply a marker in "version" time
[20:58] <javaJake> Flimm1: so, a milestone should be linked to a version number series, AFAIK
[20:59] <javaJake> Flimm1: https://help.launchpad.net/Projects/SeriesMilestonesReleases
[21:27] <neurobuntu> LarstiQ, you still here?
[21:27] <LarstiQ> neurobuntu: yes
[21:28] <neurobuntu> Would you be willing to try uploading something to launchpad?
[21:32] <LarstiQ> neurobuntu: sure
[21:32] <neurobuntu> LarstiQ, thank you
[21:32] <LarstiQ> neurobuntu: something failing to see if I'd get mail good?
[21:33]  * LarstiQ doesn't have anything 'proper' ready to upload
[21:33] <neurobuntu> I just want to know if you get any sort of notification
[21:33] <neurobuntu> I can provide you with a dummy package if you like
[21:35] <LarstiQ> I'll just reupload something, that should make it complain
[21:47] <LarstiQ> neurobuntu: "The source bzr-svn - 0.6.1-1~bazaar1~hardy1 is already accepted in ubuntu/hardy and you cannot upload the same version within the same distribution."
[21:47] <LarstiQ> neurobuntu: seems to have worked
[21:48] <neurobuntu> LarstiQ, ok hmm.. that is weird I'll mess around some more ...
[21:50] <ripps> How long until a manual depwait tries to compile again after I've upload the needed dependency?
[22:11] <neurobuntu> LarstiQ, hmm... I created a completely new package and uploaded it about 20 minutes ago and it still hasn't shown up...
[22:12] <maxb> PPA uploads should appear within 5 minutes, I think
[22:15] <devfil> hi, can someone help me? launchpad (edge) cannot import code from my git repo, it fails with an error in the python script
[22:20] <maxb> ripps: If they seem to be stuck, it may be a recurrence of bug 378828
[22:20] <LarstiQ> devfil: which one?
[22:21] <devfil> LarstiQ: http://launchpadlibrarian.net/27553657/msn-pecan-trunk-log.txt
[22:25] <LarstiQ> devfil: that looks similar to another git vcs-import that failed earlier today. Of which the bzr-git author thought he had fixed that, but lp is yet to upgrade to the fixed version
[22:25] <devfil> LarstiQ: oh great, the important thing is that the bug is fixed, thanks :)
[22:26] <LarstiQ> devfil: I believe so. If you want to make sure you could use the most recent bzr-git version yourself and branch the relevant git url
[22:27] <devfil> LarstiQ: I don't know how to use it, I prefer to wait for the new release
[22:28] <LarstiQ> devfil: that's fine too :)
[22:28] <devfil> thanks
[22:28] <devfil> bye