[00:00] <mikelifeguard> You don't see any problem with not having a useful link for potential bug reporters on bugs.launchpad.net?
[00:00] <wgrant> I do, but others do not.
[00:00]  * mikelifeguard huggles wgrant
[00:00] <mikelifeguard> let's be right together
[00:00] <mikelifeguard> we can laugh and point at everyone else
[00:00] <mikelifeguard> it'll be great!
[00:00] <wgrant> The (not too bad, actually) theory is that the project should link to the right place.
[00:01] <wgrant> Other project hosting sites don't provide links from their root, AFAIK.
[00:02] <wgrant> But Launchpad used to.
[00:27] <askhl_> Let's consider this bug: https://bugs.launchpad.net/ubuntu/+source/language-pack-gnome-da/+bug/319649 .  It "affects" a lot of different launchpad groups and projects, and it has different *status* in each of then, which makes no sense as it is only one bug, and surely a bug has only one status.  Am I misunderstanding something?
[00:27] <ubottu> Launchpad bug 319649 in fjel "Notice explaining how to get all translated strings is not translated" [High,In progress]
[00:35] <askhl_> Aside from the above, I just downloaded the po-file and checked that the notice apparently has a translation.
[00:38] <Kamping_Kaiser> is launchpad supposed to require cookies to log in?
[00:38] <Kamping_Kaiser> i just turned them off, and it refused to let me in
[00:41] <wgrant> Kamping_Kaiser: Yes, as do at least 99.99% of other websites.
[00:41] <wgrant> Probably more than that, actually.
[00:43] <Kamping_Kaiser> wgrant: yeah. most of the 99.99% i've dealt with warn about 'have you enabled cookies' instead of serving you a cryptic error message though
[00:43] <Kamping_Kaiser> wgrant: thanks for confirming, i'll ask for a change to the error
[00:44] <wgrant> Good idea.
[00:46] <wgrant> Kamping_Kaiser: You didn't happen to enable Referer blocking at the same time, did you?
[00:47] <wgrant> The message in the bug is more likely to come from omitting Referer.
[00:47] <Kamping_Kaiser> wgrant: not intentionally. i changed firefox 'accept cookies from sites' setting from enabled -> disabled
[00:47] <wgrant> Hmm.
[00:47] <Kamping_Kaiser> wgrant: when i added an exception for launchpad.net, it let me log in again
=== doctormo_ is now known as doctormo
[02:59] <lfaraone> askhl_: some bugs might be fixed in different packages, but not in others.
[03:40] <crashsystems> Does anyone know how to change a password in launchpad? I've been looking for about ten minutes.
[03:51] <wgrant> And only waited for eight.
[03:51] <wgrant> For anybody else who wants to know: try login.launchpad or login.ubuntu.com.
[03:51] <wgrant> Er, login.launchpad.net or login.ubuntu.com.
[03:51] <nigelb> login didn't work
[03:51] <nigelb> ah, spell error earlier
[06:51] <micahg> any LP admins around?
[06:55] <wgrant> micahg: Unlikely. What do you need?
[06:55] <micahg> wgrant: oh, just an offensive username
[06:56] <wgrant> micahg: Ah. I'd recommend asking an Answer.
[06:56] <micahg> wgrant: will do thanks
[07:00] <nigelb> wgrant: got a min to hack launchpadlib?
[07:00] <wgrant> nigelb: Probably.
[07:00] <nigelb> hold on, lemme paste bin
[07:01] <nigelb> http://paste.ubuntu.com/394975/
[07:01] <nigelb> this code does not recognize ubuntu members who have implied membership
[07:01] <nigelb> anyway to change that?
[07:02] <wgrant> nigelb: Perhaps model your code on http://pastebin.ubuntu.com/394569/, which I wrote to do a similar thing last night.
[07:03] <wgrant> It recurses into sub-teams.
[07:03] <nigelb> oh, great :)
[07:08] <Luctor> hi
[07:09] <Luctor> quick question : is it possible to check how many times a package from your ppa has been downloaded ? i.e. downloads stats for a ppa ..
[07:10] <wgrant> Luctor: I
[07:10] <wgrant> I've got a series of branches that does just that in the review queue.
[07:10] <wgrant> So you should see that feature appear in around two weeks, unless something goes really wrong.
[07:11] <Luctor> how cool !
[07:11] <Luctor> thanks
[07:12] <Luctor> https://code.launchpad.net/~wgrant/launchpad/ppa-download-stats  !
[07:13] <wgrant> Luctor: That's one of them, yeah.
[07:13] <Luctor> launchpad is awesome ...
[07:14] <wgrant> Yep.
[07:14] <Luctor> i wanna marry it, but I don't think that's legal in my country
[07:14] <wgrant> Heh.
[07:14] <wgrant> Laws can change :P
[07:14] <Luctor> and my wife won't let me, probably ...
[07:15] <Luctor> lol
[07:15]  * Luctor needs coffee
[07:35] <nigelb> wgrant: you use the latest lplib?
[07:37] <wgrant> nigelb: Yes. You may need to replace the login_anonymously() call to use it on an earlier version, but that's about it.
[07:38] <nigelb> wgrant: yeah, thats where things went wrong
[07:38] <wgrant> Replace it with an older get_token_and_login or login_with call.
[07:41] <nigelb> wgrant: is there something like is_member_of (team) kind of action on the api?
[07:41] <nigelb> or do I still follow the same process I followed
[07:42] <wgrant> inTeam is hard to export safely due to private teams.
[07:43] <nigelb> i only want to check if a person is an ubuntu member
[07:43] <wgrant> Ah.
[07:43] <nigelb> i.e., input a team and should return the list of ubuntu members
[07:44] <wgrant> nigelb: You may be able to just iterate over person.super_teams to find out if they're in ~ubuntumembers.
[07:44] <wgrant> Or you could iterate over all members of both teams, and take the intersection of the sets.
[07:45] <nigelb> thats what I'm doing right now
[07:45] <wgrant> Ideally you could say person.inTeam(ubuntumembers), but that's not possible yet.
[07:45] <nigelb> I wanted to just know if there was a need to iterate
[07:45] <wgrant> Sadly there is.
[07:45] <nigelb> lp api is awfully slow
[07:45] <wgrant> It depends where you are.
[07:45] <nigelb> especially with this sort of iteration
[07:45] <wgrant> From my place in .au it's horribly slow.
[07:46] <nigelb> well, .in and .us too
[07:46] <wgrant> From a server I control that's just a few milliseconds away from LP, it's much much faster.
[07:46] <wgrant> Still not really fast, but quite usable.
[07:46] <nigelb> ah
[07:46] <nigelb> milliseconds away?
[07:46] <nigelb> wow
[07:47] <wgrant> rtt min/avg/max/mdev = 1.223/1.320/1.419/0.082 ms
[07:48] <mwhudson> so canonical should buy shares in london-hosted vps providers?
[07:49] <wgrant> Or superluminal communication.
[09:04] <qense> A surprising amount of heath for this small bug #538563
[09:04] <ubottu> Launchpad bug 538563 in xchat-indicator "Messaging Indicator plugin cannot be set to enabled in XChat-GNOME" [Undecided,New] https://launchpad.net/bugs/538563
[09:05] <wgrant> qense: It's probably because you're viewing it in the context of the source package.
[09:05] <wgrant> So it's finding a very low maximum heat value across all of the context's bugs.
[09:05] <qense> wgrant: ah, that'd explain, thanks
[09:06] <qense> is that a recent change or has it always worked like that?
[09:06] <wgrant> It's been around a couple of weeks, IIRC.
[09:06] <wgrant> You can see the exact heat value in a tooltip on the flames.
[09:07] <qense> I saw that, it's good
[09:07] <qense> If only I could sort bug lists on heat... ;)
[09:07] <qense> I do know an URL for that, I'm just lazy and want to be able to click.
[10:56] <pep> I'm not sure if I should report a bug, because maybe it's just me not seeing it correctly, but the link in my launchpad profile homepage is not linkified... can someone confirm this? https://edge.launchpad.net/~pep.
[10:58] <pep> and hello everyone =) I forgot to greet!
[10:59] <nigelb> pep: I didn't understand what you're trying to say
[11:00] <pep> Well, in the "Homepage Content" of one's launchpad profile, links are automatically linkified if I'm not mistaken... so there's no need for <a> or [link] tags of some sort.
[11:01] <wgrant> pep: I see no homepage content there, but it is normal for it to not be linkified until a day or two after you start doing work in Launchpad.
[11:01] <pep> But for some reason, I don't see my link appearing as such.
[11:01] <wgrant> (this is to prevent spammers from using lots of accounts to link to places)
[11:02] <pep> Oh right, because it used to be linked and formatted, now the new-line and linkification seem to have dissapeared.
[11:02] <pep> I understand!
[11:02] <wgrant> Right, this changed a couple of months ago.
[11:03] <pep> It's true that I have been quite inactive for the months, but being on launchpad again lately I noticed this... thank you the explanation.
[11:03] <pep> past months* that is
[11:03] <pep> No worries then, have a nice day.
[16:16] <om26er_LHSWC> any one at launchpad can change the privacy of a bug?  bug 537262 was changed to private from a member who seem to have just made an account at launchpad
[16:16] <ubottu> Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/537262)
[16:18] <micahg> om26er_LHSWC: aren't you in bug control?
[16:18] <om26er_LHSWC> I am bug any one can change the privacy?
[16:19] <om26er_LHSWC> s/bug/but
[16:19] <micahg> om26er_LHSWC: if you're in -bugcontrol you can change it
[16:22] <om26er_LHSWC> micahg, ok done but the actual question is any one in launchpad without being a member of any team (not even the reported of the bug) can change the privacy?
[16:22] <micahg> om26er_LHSWC: yes, if it's public
[16:23] <om26er_LHSWC> micahg, ah, ok thanks :)
=== yofel_ is now known as yofel
=== om26er_LHSWC is now known as om26er
[16:39] <nocnokneo> hi all
[16:40] <nocnokneo> I'm a debian packaging newbie looking for a little advice with a ppa build that is failing
[16:41] <nocnokneo> i actually have two problems, in the process of trying to re-upload a fixed source package with dputs -f I'm getting a new error
[16:41] <nocnokneo> Rejected:
[16:41] <nocnokneo> File add-remote-torrent_0.1.diff.gz already exists in nocnokneo, but uploaded version has different contents. See more information about this error in https://help.launchpad.net/Packaging/UploadErrors.
[16:41] <nocnokneo> Files specified in DSC are broken or missing, skipping package unpack verification.
[16:42] <nocnokneo> do I have to bump the version to -1?
[16:43] <nocnokneo> (I'd rather not bump the version like that every time I make a rookie mistake)
[16:44] <nocnokneo> the root problem that I am trying to solve is this build error:
[16:44] <nocnokneo> https://launchpad.net/~nocnokneo/+archive/ppa/+build/1560658/+files/buildlog_ubuntu-karmic-i386.add-remote-torrent_0.1_FAILEDTOBUILD.txt.gz
[17:09] <micahg> nocnokneo: https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#versioning
[17:13] <nocnokneo> thanks for the link
[17:13] <nocnokneo> I don't see any mention of the case where the upstream creator is also the package maintainer
[17:14] <Some_Person> Do the launchpad build machines have internet access?
[17:14] <nocnokneo> in this case do I still use 0.1-1 versioning scheme? or can I just distribute the package with the correct debian/* files and use the orginal 0.1 version number
[17:17] <micahg> nocnokneo: the doc give hints on versioning including adding a suffix so you can bump versions of the package without bumping versions of the app
[17:21] <Some_Person> To rephrase, can I download files as part of building the package?
[17:22] <elmo> Some_Person: no
[17:22] <Some_Person> darnit
[17:22] <Some_Person> I'm tired of uploading ~75MB every time I want to update my package
[17:24] <Some_Person> I was hoping the launchpad build machine could just do the svn checkout part for me
=== geser_ is now known as geser
[17:42] <maxb> It's fundamentally the intent of packaging that everything needed to build the package is actually in the source package and its dependencies, sorry.
[17:44] <Some_Person> Yeah, but packagers aren't expected to have slow connections either
[17:47] <geser> Some_Person: do you have access to an server with a better connection? if yes, you could upload from there
[17:48] <Some_Person> Nope, this is all I have
[17:48] <Some_Person> I'm a 16 year old. Do you really expect me to have fancy servers with fast connections?
[18:21] <maxb> Fundamentally the requirement to upload the source you want built doesn't seem *that* ridiculous
[18:32] <rye> Hello, is there anything wrong with launchpad - I can't file any bug, since apport says "Cannot connect to crash database, please check your Internet connection."
[18:46] <BlackZ> rye: yes, it's an launchpad issue, we're already informed
[18:46] <BlackZ> bug #538097
[18:46] <ubottu> Launchpad bug 538097 in launchpad "Apport cannot connect to crash database" [Undecided,Confirmed] https://launchpad.net/bugs/538097
[18:46] <rye> BlackZ, ok, I just thought that launchpadstatus on identica might be worth updating :)
[19:12] <coffeeburrito> How do I control who can commit to a branch of code on launchpad?
[19:13] <nhandler> coffeeburrito: Go under 'Change Branch Details' and change the Owner
[19:13] <coffeeburrito> oh
[19:13] <coffeeburrito> that's odd then
[19:13] <coffeeburrito> it's set to me
[19:14] <coffeeburrito> but my initial commit didn't say it was me
[19:14] <nhandler> coffeeburrito: Where did you push the branch to ?
[19:14] <coffeeburrito> https://code.launchpad.net/~coffeeburrito/orgdir/development
[19:14] <coffeeburrito> just that it said the commit was "joe <joe@uzod2>"
[19:14] <nhandler> coffeeburrito: That is why. Notice the ~coffeeburrito part ;)
[19:14] <maxb> Branch owner controls who can push - it has nothing to do with the identities that are attributed to the commits
[19:15] <coffeeburrito> I guess I falsely assumed that since it did not know it was me committing, that it was open acces s:p
[19:15] <maxb> It knew it was you *pushing*
[19:15] <coffeeburrito> ahha
[19:16] <micahg> we're not importing comments from xfce bugzilla are we
[19:16] <coffeeburrito> so then next question is how to configure bzr to show my name for commits
[19:16] <maxb> coffeeburrito: You'll need to use a real email address when committing, and have that address registered with launchpad, before launchpad will be able to link your LP identiy to commitsw
[19:16] <coffeeburrito> the launchpad name, that is
[19:17] <coffeeburrito> I have a real email registered with launchpad
[19:18] <james_w> bzr whoami
[19:18] <coffeeburrito> joe <joe@uzod2>
[19:18] <james_w> bzr help whoami
[19:19] <coffeeburrito> ah nifty
[19:19] <coffeeburrito> thanks :)
[20:59] <wgrant> lamont: LP's buildd scanning code has for years had a very odd behaviour where it will avoid scanning builders if they have no assigned DASes with chroots. I'm guessing you don't value that at all?
[21:05] <lamont> DASes?
[21:06] <lamont> wgrant: I'd love for the builder to tell launchpad what architectures it's willing to build for, and launchpad to schedule builds for all of the above, in some order
[21:06] <lamont> many of our buildds could be building amd64/i386/lpia bits with no extra effort
[21:06] <wgrant> lamont: DistroArchSerieses.
[21:07] <wgrant> lamont: I have code for both sides that lets LP tell the buildd what arch to be, but it relies on arch configuration in the DB, not the slave.
[21:07] <lamont> wgrant: either way, but I want multiple architectures per slave
[21:08] <lamont> Ithink the "don't scan if no chroots for DAS" is just realizing that we won't actually schedule anything if the buildd is idle, so why bother even looking
[21:08] <wgrant> lamont: I think everyone does.
[21:08] <wgrant> lamont: Yeah, but that's not going to happen in practice except once we kill hppa properly or introduce a new arch.
[21:09] <wgrant> And if I can remove the behaviour I can simplify complicated code and delete hundreds of lines...
[21:09] <lamont> lpia will be there for a while
[21:09] <lamont> as will hppa
[21:09] <lamont> hppa/jaunty means that we'll have hppa/hardy until 2013.  ditto for lpia
[21:09] <wgrant> Right. So it's probably not going to be useful for years.
[21:10] <lamont> likewise, there shouldn't be any builds queued for any of those architectures, so as long as it doesn't faceplant, I don't care if it scans the builders
[21:10] <wgrant> And even when it will be, the same can be achieved by marking the builders NOT OK.
[21:10] <wgrant> Great.
[21:10] <wgrant> It just won't do anything -- nothing will break.
[21:10] <lamont> well, hardy-security still gets uploads for both architectures
[21:11] <wgrant> Right.
[21:11] <wgrant> My current multi-arch buildd-master implementation is a hack, but the slave is fine. I've been thinking about how to do the master properly.
[21:11] <wgrant> Should we allow selection of multiple processors, or should we create capability relations between processors?
[21:11] <lamont> so yeah - as long as builds for things that are queued happen, and we don't face plant, I have no issue with scanning the buildd to notice that it's idle,still, lo these 6 months, every pass
[21:12] <lamont> the real crux is that when there isn't a chroot for the DAS, we don't generate build records for uploads to that DS
[21:12] <wgrant> Right, that's been done forever and is unrelated.
[21:12] <lamont> right
[21:12] <lamont> so...
[21:12] <wgrant> (although the code is right next to it, for reasons that make no sense and I'm about to fix)
[21:12] <lamont> I'm not sure that there is any existing amd64 processor that we would say "never build i386/lpia" on
[21:13] <wgrant> Right.
[21:13] <lamont> we do want to have a primary arch for something, I suspect, but we could certainly just have "amd64 only" and "amd64 and possible others"
[21:13] <lamont> "amd64 and subset"
[21:14] <wgrant> How would you define when to use the primary arch, and when to not?
[21:19] <wgrant> It might just be easier to provide a list of checkboxes for each builder.
[21:20] <wgrant> That allows full flexibility, and you're never going to need to check more than three.
[21:22] <wgrant> lamont: Also, I see you have an lp-buildd umask(022) branch outstanding -- is that going to land at some point? It would be nice to remove the local changes that everyone has.
[21:28] <lamont> wgrant: we need to land the umask-in-init.d branch, don't really care about the umask-in-sbuild branch
[21:29] <lamont> both branches have existed at some point :-(  and I think the one I don't care about has landed, and the one we need (karmic and later twisted defaults to 077, which is fatal to our assumptions, and therefore us) so we'll need that for lucid rollout next month
[21:30] <wgrant> lamont: Neither has landed.
[21:30] <wgrant> umask-in-sbuild has been approved, though.
[21:31] <wgrant> I've been using the init.d fix for many months now, but I haven't seen a branch for it besides mine.
[21:31] <lamont> https://code.edge.launchpad.net/~lamont/launchpad/lpbug-537733
[21:32] <lamont> amusingly, that branch seems to have a bunch of unrelated stuff... either I pulled from the wrong place, or I just plain suck at bzr
[21:33] <wgrant> Looks like you branched from devel but proposed to db-devel.
[21:33] <wgrant> You should have proposed against lp:launchpad/devel.
[21:34] <wgrant> Which version of lp-buildd is running in production at the moment?
[21:34] <wgrant> A post-recipe one?
[21:35] <wgrant> Because we have backwards compat hacks on both sides to cope with the transition, and it would be nice to start killing them before they get forgotten.
[21:39] <lifeless> lamont: its not bzr, its how lp dev is structured
[21:41] <lamont> I want to say 56 or 57 - which ever it was, it was derived from the prior version rather than from launchpad, since they broke the build in launchpad about the time I needed to roll it
[21:42] <lamont> the init.d change is cowboyed on the karmic buildds (ppc)
[21:42] <wgrant> Oh, the PPC buildds aren't prehistoric any more?
[21:42] <lamont> they're karmic
[21:42] <lamont> amusingly, the only machine that seems to fall over on a regular basis with post-dapper kernels is not a buildd
[21:43] <lamont> for extra credit, tell me how to get an IBM XServe to have a serial console, so I can capture the OOPS and maybe get it fixed.
[21:43] <wgrant> Heh.
[21:53] <lamont> was recipe the "run something more than just sbuild" changes?
[21:53] <wgrant> lamont: Yes.
[21:53] <lamont> then yeah, we still need to do that transition
[21:54] <lamont> remind bigjools to remind me to deal with it and we'll roll something to make it all better
[21:54] <wgrant> The specific change I'm interested in is my lp-buildd 57 in devel.
[21:54] <wgrant> Which renames the primary build manager from 'debian' to 'binarypackage', and adds a 'debian' alias to it.
[21:54] <lamont> 56 is what we're running
[21:54] <wgrant> Damn, OK.
[22:00] <crimsun> try as I might, bug 519387 simply will not successfully convert to a question
[22:00] <ubottu> Launchpad bug 519387 in pulseaudio "Pulseaudio is not running" [Undecided,Incomplete] https://launchpad.net/bugs/519387
[22:00] <crimsun> doesn't matter if I use edge or production, because oopses abound
[22:03] <wgrant> crimsun: Proper OOPSes or timeout OOPSes?
[22:03] <wgrant> Ah, lots of comments. Probably timeouts.
[22:03] <crimsun> timeout oopses
[22:04] <crimsun> also, can I convert a remote branch's pack repo format from 1 to 2a?
[22:05] <crimsun> I've tried 'bzr upgrade' locally and push --overwrite, but it doesn't appear to do what I want; am I doing something wrong?
[22:05] <crimsun> (bzr is current Lucid's)
[22:05] <wgrant> crimsun: You would need to bzr upgrade lp:blah, or click the 'Upgrade branch' link on LP.
[22:05] <wgrant> Push doesn't change the format.
[22:05] <crimsun> wgrant: ok, thanks
[23:48] <A4Tech> All greetings. I have a problem with the attempt to re-compile the package on Launchpad
[23:48] <A4Tech> File file.tar.gz already exists in ITmages myppa, but uploaded version has different contents. 
[23:50] <A4Tech> I looked here https://help.launchpad.net/Packaging/UploadErrors there written about this error, but did not understand how to do so would have happened
[23:55] <krisives> Does anyone know why this package isn't in Lucid ? https://launchpad.net/ubuntu/+source/gtkdialog