[00:01] <jwal> Do you have the bug link for the build-dep generation idea?
[00:03] <jelmer> not here, though it's not much more than what I just described - a programmatic way to update the source dependencies based on the upstream branch
[00:05] <jwal> Just guessing, was this suggested to support an maven-based build?
[00:06] <jelmer> jwal: nope
[00:07] <jwal> Are we going to end up with the recipe being any shell/python script with the power to install dependencies at will?
[00:08] <jelmer> jwal: if we're going to end up with something like that it would be about updating the existing debian/control file's Build-Depends{,-Indep}, not about installing packages itself
[00:10] <jwal> You're right again, of course
[00:11] <jwal> If you derive the Build-Depends{,-Indep}, would you want the result of that derivation to be included in the manifest?
[00:14] <achiang> wgrant: i thought LP was smart enough to have a dependency-wait state. say i upload package A to a ppa, and B has a build-dep on it
[00:14] <achiang> wgrant: shouldn't LP wait on building B until A is done?
[00:15] <achiang> wgrant: i only ask because i thought i saw that behavior before, and i'm seeing different behavior now
[00:15] <wgrant> achiang: It will try to build B, but sbuild will notice the deps are missing. It will report that back to LP, and it will depwait.
[00:15] <achiang> (but i could be quite wrong)
[00:15] <wgrant> But if the deps are present but uninstallable, it cannot be automatically retried, so it will fail to build.
[00:15] <achiang> wgrant: does it only work for missing packages? or is smart enough even to notice versioned dependencies?
[00:17] <jelmer> jwal: probably, it'd be hard to guarantee the manifest is deterministic otherwise
[00:17] <wgrant> achiang: It works for versioned dependencies too.
[00:17] <wgrant> Minus a couple of rare glitches that I forget the details of.
[00:17] <achiang> wgrant: hm, so if i see different behavior, should i file a bug?
[00:18] <jwal> jelmer: Would I be right to assume that the manifest currently does not contain the source tree, just the bzr revision numbers that were merged?  Do you have an example manifest somewhere?
[00:18] <wgrant> achiang: You should tell me, then I'll tell you if you should file a bug :)
[00:18] <achiang> heh
[00:19] <jelmer> jwal: yes, that's right.
[00:19] <jelmer> jwal: manifests basically are recipes with revisions explicitly specified everywhere
[00:19] <jwal> Hence you don't want to run a script with the power to modify the source tree
[00:19] <jwal> Like a log
[00:21] <jelmer> jwal: right, building a particular manifest should result in the same exact tree being constructed each time.
[00:30] <jwal> Jumping backwards for a moment, there is some kind of hook prior to building the source package.  dpkg-source --before-build even has a special source format called "3.0 (bzr)".  That does not seem to help here, though, we'd have to add extra behaviour.
[00:30] <cjwatson> 3.0 (bzr) isn't TBH all that desperately useful (speaking as its author
[00:30] <cjwatson> )
[00:30] <cjwatson> it was an experiment
[00:31] <jwal> Ah :)
[00:33] <poolie> hello cjwatson
[00:33] <poolie> i'd like to look at https://dev.launchpad.net/LEP/BuildFromBranchIntoMain with you sometime
[00:34] <wgrant> Can we s/Main/Primary/?
[00:34] <poolie> sure
[00:34] <poolie> what does Primary mean here?
[00:34] <wgrant> The primary archive.
[00:34] <wgrant> PPAs have main too.
[00:35] <wgrant> In fact, they *only* have main.
[00:35] <poolie> of course
[00:35] <poolie> yes, that's better
[00:35] <poolie> the name is just what it's tended to be called in the past
[00:35] <wgrant> Given that it's on the LP dev wiki, in particular.
[00:36] <cjwatson> poolie: ok, maybe not at past midnight local though :)
[00:36] <poolie> sure :) no rush
[00:36] <cjwatson> I'm just waiting for my router's Debian upgrade to finish
[00:37] <jwal> jelmer: Time for sleep.  It was nice speaking with you.
[00:39] <jelmer> jwal: Yeah, you too. I should probably get some sleep too. g'night!
[02:43] <Raydiation> hm launchpad overload?
[02:43] <Raydiation> i cant report  a bug
[02:46] <lifeless> what happens
[02:46] <Raydiation> ok works
[02:46] <Raydiation> server timeouts a lot
[04:13] <achiang> does a package in depwait automatically build after the dependencies are satisfied?
[04:13] <achiang> or do i manually need to go press "retry this build" ?
[04:13] <wgrant> Unless they are virtual packages, it should be automatically retried within an hour.
[04:13] <achiang> ok, thx
[06:06] <poolie> who has permission to upload release files?
[06:22] <lifeless> poolie: drivers, owner, series owner, I think.
[06:23] <poolie> thanks; all good now
[09:59] <aksinha_> I trying to get branch from launchpad ..using bzr branch..but getting ssh connection refused
[09:59] <aksinha_> seems like i am behind a firewall...
[10:00] <aksinha_> so is there any way for branching my code without doing bzr+ssh
[10:00] <Peng> aksinha_: http
[10:01] <Peng> aksinha_: Which would be read-only.
[10:01] <Peng> Blocking SSH? Ugh, that's terrible.
[10:02] <aksinha_> Peng: i could get my ssh unblocked from my university..if that is the better solution
[10:02] <aksinha_> otherwise i have to go with http
[10:02] <Peng> aksinha_: Getting SSH unblocked is a great solution. SSH is awesome and used for many things.
[10:02] <Peng> 'course, if you don't use it...
[10:33] <cody-somerville> Peng, read-only access is available via https
[10:33] <Peng> Oh? Didn't know that.
[10:36] <wgrant> cody-somerville: Is it?
[10:36] <wgrant> We have private codebrowse on HTTPS.
[10:36] <wgrant> But we don't actually serve branches from there.
[10:37] <cody-somerville> maybe just http then?
[10:38] <cody-somerville> yea, just http and not https it appears
[10:57] <tumbleweed> spam report (that I've mentioned a few times already, and won't mention again, we really do need a better way to deal with this...) https://bugs.launchpad.net/ubuntu/+source/rbot/+bug/604102/comments/5
[10:58] <cdbs> tumbleweed: I think the correct process to deal with spam is to file a question in LP mentioning about it
[10:59] <tumbleweed> err I suppose
[10:59] <cdbs> and LP admins will deal with it there
[11:04] <bigjools> the account was suspended
[11:06] <tumbleweed> bigjools: aah thanks
[11:06] <bigjools> I didn't suspend it btw, was just pointing that out :)
[13:12] <dpm> jtv, now that the translations imports queues for Ubuntu are disabled, what happens to the translations people manually upload or that are uploaded through source package uploads during this time? Are they still put on the queue, so that they can be processed when it it reenabled, or are they just lost?
[14:06] <jtv> dpm: sorry, lunch.  The uploads all stay on the queue, being overwritten only by replacement uploads to the same pofiles by the same person.
[14:07] <popey> could an admin please look at https://bugs.launchpad.net/ubuntu/+source/ubiquity-slideshow-ubuntu/+bug/606134/comments/7 / https://launchpad.net/~michael-luetz which looks spammy.
[14:09] <dpm> thanks jtv, so in the case of the same uploader we're all good, but if there are different uploaders we might end up processing many translations that are obsolete (i.e. we'd only want the latest upload, but we'll process imports from different uploaders)
[14:09] <dpm> is that correct?
[14:09] <jtv> Yes,
[14:09] <jtv> but
[14:10] <jtv> our imports are optimized so that repetitions of existing messages take up very little time.  Whatever isn't a repetition, even if it's not the eventual translation, may still be useful as suggestions.
[14:11] <dpm> ok, thanks jtv
[14:14] <exarkun> I merged lp:~game-hackers/game/installation-instructions into lp:game an hour ago, but lp:~game-hackers/game/installation-instructions still appears on https://code.launchpad.net/game
[14:14] <exarkun> Why is that?
[14:49] <deryck> exarkun, you have to set the status on the merged branch to "Merged"
[14:49] <deryck> exarkun, I don't believe there's anything that does this automatically on lp.  groups have scripts or merge tools that do this for them, I think.
[14:50] <deryck> abentley could confirm this ^^
[14:50] <abentley> deryck, the branch scanner automatically detects merges and marks them.
[14:51] <exarkun> Should I report a bug, then?  Or am I just too impatient?
[14:52] <deryck> ah, see there.  Glad we asked abentley :-)
[14:52] <abentley> exarkun, I'll have a look.
[14:55] <abentley> exarkun, we detected a merge in the opposite direction, from lp:game => lp:~game-hackers/game/installation-instructions and lp:~amacleod/game/client-invocation => lp:~game-hackers/game/installation-instructions
[14:55] <exarkun> That's a funny thing to have detected.
[14:56] <exarkun> Am I using bzr wrong?  Or is it a bug in the branch scanner?
[14:56] <abentley> That was at 12:55.
[14:57] <abentley> At 13:00, I see Merge detected: lp:~game-hackers/game/installation-instructions => lp:game
[14:58] <abentley> And it says "lp:~game-hackers/game/installation-instructions now Merged", which I believe means it set the branch to Merged.
[14:59] <exarkun> But it shows up on https://code.launchpad.net/game as "Development"
[15:03] <abentley> exarkun, after it was marked merged, it looks like another revision was pushed.
[15:05] <exarkun> The last revision on the branch is divmod.com-20110209125926-8d98psdzhqru0vrs and that revision was also included in the merge
[15:06] <exarkun> So maybe the scanner noticed the revision after it noticed the merge, but the merge happened after the revision
[15:07] <abentley> exarkun, I can say for sure that pushing new revisions will mark a branch as "development".  I'm not sure why it didn't get re-marked as Merged.
[15:14] <abentley> exarkun, I guess you should file a bug.
[15:14] <exarkun> abentley: Okay, thanks!
[16:46] <dpm> Hi, could a maintenance squad have a look at bug 715854? It's causing us problems in building the language packs for the 10.04.2 release next week. We might have a workaround for the languages affected, but we'll hit the same problem when building the maverick language packs next
[16:48] <dpm> and the natty ones
[16:53] <mtaylor> hey all - can anybody suggest either a best-practice guide to translations in python projects or a project using translations i can look at to see how they're doing it?
[17:01] <dpm> mtaylor, I'd recommend giving quickly a try. It will create the skeleton of a python app for you with translations enabled. You can just create a test project and have a look at the structure. For example:
[17:01] <dpm> quickly create -t ubuntu-application testproject
[17:01] <mtaylor> dpm: good call. thanks
[17:01] <dpm> running that command will create the test project for you
[17:03] <mtaylor> dpm: there doesn't seem to be any translation infrastructure in the results of that :(
[17:03] <mtaylor> dpm: I take that back...
[17:04] <dpm> hmm, there should be: gettext initialized, using python-distutils-extra to manage translations, etc. Let me have a look...
[17:05] <mtaylor> dpm: yeah - my bad, I see it now... so, given such a branch, how does integration with launchpad translations work?
[17:05] <mtaylor> dpm: does everything do the magical right thing?
[17:06] <dpm> mtaylor, absolutely! :) . Just run "python ./setup.py build_i18n" to create the po folder and the po/testproject.pot template. Then commit the .pot file and you're ready to enable translations in LP:
[17:07] <mtaylor> dpm: sweet. thanks! I was trying to do all of this with babel and it was starting to give me hives. this seems must more integrated and happy
[17:09] <dpm> mtaylor, here you'll find the steps and tips for enabling translations in LP: hhttps://help.launchpad.net/Translations/YourProject/BestPractices#Set%20up%20your%20project%20in%20Launchpad
[17:09] <dpm> once you've set up the bzr branch, enabling translations should be a cuple of clicks away
[17:10] <dpm> couple
[17:10] <mtaylor> dpm: totally - those steps I'm good with - it's just that all the projects I'd done in the past were c/c++ and intltool
[17:11] <dpm> mtaylor, ahh yeah. Integration works even slightly better with intltool-based projects, as LP can automatically generate the .pot file from the branch without you having to worry about anything else than committing
[17:12] <mtaylor> yup. that's a thing of beauty
[17:12] <thumper> hi mtaylor
[17:12] <dpm> absolutely :)
[17:12] <mtaylor> the part that's been hard to find is a best-practices doc for how to get the python project itself set up for translations... so the quickly suggestion was quite handy
[17:12] <mtaylor> hi thumper
[17:12] <mtaylor> thumper: write better docs for things you don't work on!
[17:13] <thumper> ah... whut?
[17:13] <mtaylor> thumper: just kidding
[17:13]  * thumper is not entirely awake yet
[17:13]  * mtaylor punches thumper in the kidney to get his day started off properly
[17:14]  * thumper shrugs off mtaylor's puny attack
[17:20] <taljurf> guys, ive entered my ssh, but when i try to branch, launchpad doesn't allow me
[17:21] <taljurf> any sol?
[17:22] <taljurf> nm
[17:22] <taljurf> another thing, is there any way to change my launchpad id?
[17:23] <taljurf> nm again
[17:30] <achiang> hello, i have a bzr branch linked to a bug. i want to delete the branch, and it's saying, "The following items must be deleted" and points at the bug
[17:30] <achiang> does that mean the bug itself is deleted, or just the link to the bug?
[17:31] <cody-somerville> achiang, just the link
[17:32] <achiang> cody-somerville: thanks
[18:06] <mtaylor> dpm: sorry to bug you again - but with using distutilsextra.auto, now I'm getting a crapton of warnings about WARNING: the following files are not recognized by DistUtilsExtra.auto:
[18:07] <mtaylor> dpm: I have them listed in MANIFEST.in - is there any way to silence that?
[18:08] <dpm> hey mtaylor. hm, I'm not sure there is. The best thing would be to ask pitti on #ubuntu-devel or #ubuntu-desktop. He's the maintainer and should be able to help more
[18:09] <mtaylor> dpm: woot. will do. thanks
[18:09] <dpm> no worries :)
[18:39] <mounir> Does launchpad mailing list supports aliases?
[18:40] <lifeless> what do you mean?
[18:41] <mounir> The reason I am asking is the following: Linaro Burndown charts are picking up Work Items for project members
[18:41] <mounir> but these WI's are not for Linaro Blueprints
[18:42] <mounir> So I am trying to figure out a way to differentiate between Work Items for the same team member, maybe by using aliases
[18:44] <mounir> So the idea is to have 2 or more aliases for the same team member, then use an alias for Linaro and anothe alias for something else
[18:50] <lifeless> mounir: why not just filter by project?
[18:52] <mounir> lifeless: I have no control over the program that does the burdown charting, I think it is a python program, the last I heard was it was very hard to implement
[18:53] <lifeless> mounir: have a chat to james_w - its a very simple program really.
[18:54] <lifeless> mounir: but to answer the question, launchpad accounts have no aliasing facility; a login is a single account, and that account is linked to all activity of that login
[18:54] <mounir> lifeless:  That is who I was talking with James-w,  I think it is a function of how much he has on his plate
[18:55] <lifeless> if someone wants two accounts, they need to have two signons, and each singon needs a unique email address
[18:55] <mounir> lifeless: So aliases is not supported?
[18:55] <james_w> mounir, this is lool's workitems showing up on the kernel team's page?
[18:55] <lifeless> mounir: no, we have no concept of account aliases
[18:55] <mounir> James_w yes and Mathias in Toolchain as well
[18:56] <lifeless> and frankly, changing the WI tracker will be massively less work than adding account aliases to LP
[18:56] <lifeless> we could, but this doesn't seem like a particularly compelling use case for adding them; and they would have considerable UI and performance impact
[18:56] <james_w> right, I've said that I don't think it's a big problem, and that we can easily fix it by removing the people from the teams if they are not part of the team
[18:57] <james_w> if you disagree, and we can't fix it by removing them then you need to tell me that it is important and we can change the way the data is gathered
[18:58] <mounir> James_w, removing people from the team is not a solution really, as I forsee this problem creeping on us all the time now and the future. I have asked the team Leads and they have rejected the idea
[18:59] <james_w> why would it creep?
[18:59] <mounir> New members may join the team (let us the toolchain WG) but they have other item in other projects they are handling
[19:00] <mounir> s/let us/let say/
[19:00] <james_w> well, that's not the issue with lool
[19:00] <james_w> or Mattias
[19:00] <james_w> and I would contend that the team leads want to know when engineers are spending time on other projects
[19:01] <mounir> James_w how it is not? they have WI's under other projects and these WI's are showing on the Linaro groups
[19:01] <james_w> mounir, because they aren't part of the team really.
[19:02] <mounir> James_w, this is messing up the Status of the releases, we don't know the correct status of Linaro releases for a particular group.
[19:02] <james_w> fair enough
[19:03] <james_w> I just want to understand which issues you are concerned about, and come up with the right fix for all of them
[19:03] <mounir> as additional items are showing as art of their work on Linaro
[19:03] <mounir> James_w, maybe we have to move this discussion from this channel and bring up on the email
[19:03] <james_w> if you want to have Loïc be a member of ~linaro-kernel-wg, despite him being in OCTO, then I can make changes such that his workitems won't show up on the kernel team page
[19:04] <james_w> however, that does nothing about the other issue you bring up, and toolchain engineers who work on "non-toolchain" projects too
[19:04] <mounir> James_w, don't make special case for LooL, as I said Mathias has the same issue, we need a general solution
[19:05] <james_w> well, I would fix it for Mattias and Loïc, and it would allow you to add anyone else to the list that you like
[19:05] <james_w> however, it wouldn't deal with the other issue at all
[19:06] <mounir> James_w, can you send you suggested solution to the linaro.org mail and copy the Team leads, if they are ok with it, I should be as well
[19:06] <james_w> mounir, sure.
[19:07] <mounir> James_w, thnx
[20:53] <cody-somerville> Hi. I have a P3A where there is a binary from a superseded version of a source package; ie. the published version of the source package no longer produces the binary in question but the old version is sticking around for some reason.
[20:59] <erkan^> what mean "karma"?
[21:02] <james_w> cody-somerville, that's expected in the primary archive. Do PPAs normally behave differently there?
[21:03] <cody-somerville> I would hope so since I'm not sure there is any way for me to manually have the binary removed.
[21:03] <james_w> cody-somerville, yeah, that's what I'd think too
[21:03] <james_w> I know wgrant will know for sure
[21:06] <james_w> cody-somerville, there is a requestDeletion() on binary_package_publishing_history on the API
[21:07] <james_w> cody-somerville, it's docstring is a little worrying, but I would guess that was to do with inheritance
[21:07] <james_w> it might unblock you if you want to try it
[21:09] <cody-somerville> james_w, kudos. Will look at it.
[21:09] <wavez> I am having trouble getting a package that I have added.
[21:09] <wavez> this is the error
[21:09] <wavez> http://paste.pound-python.org/show/2683/
[21:23] <maxb> wavez: You have added an URL to a PPA which does not exist or no longer exists
[21:29] <wavez> maxb: how to remove a ppa?
[21:29] <maxb> Remove the lines concerned from /etc/apt/sources.list, or, possibly remove the file concerned from /etc/apt/sources.list.d/
[21:31] <wavez> the problem is that I did 'sudo add-apt-repository ppa:habnabit/hab-name'
[21:31] <wavez> hab-name needs to be hab-ppa
[21:31] <wavez> maxb: there is no 'sudo remove-apt-repository'?
[21:31] <lifeless> ppa-purge
[21:34] <wavez> This is such a headache
[21:35] <maxb> Why? All you need to do is delete a few lines from a configuration file
[21:38] <wavez> maxb: I looked at installing ppa-purge. Too much work.
[21:38] <wavez> maxb: there are no lines containing the offending package name in sources.list
[21:38] <wavez> hab-name is the name I used in error
[21:38] <wavez> no lines of the file contain the word "name"
[21:39] <maxb> wavez: You only need ppa-purge to automate removal of all packages currently installed on your system that came from PPAs that are no longer in your configuration. You do not need it to remove the configuration itself
[21:39] <maxb> wavez: If it is not in /etc/apt/sources.list, then it will be in a file contained within /etc/apt/sources.list.d/
[21:39] <wavez> ok
[21:42] <wavez> maxb: okay, I removed them and apt-get update finished without error. Thank you.
[21:46] <landrover> Hello, I am trying the automatic daily source builds, and am hitting this error:
[21:46] <landrover> dpkg-source: error: can't build with source format '3.0 (quilt)': no orig.tar file found
[21:46] <landrover>  
[21:46] <landrover> is it something obvious to anyone? (not me :-)
[21:47] <landrover> it's result of running bzr dailydeb ...
[21:47] <poolie> landrover, ah, you probably didn't include the orig tar
[21:48] <poolie> this is often a problem when rebuilding something that came from ubuntu or debian
[21:49] <landrover> poolie: it's daily build from bzr code, which should fetch the code from bzr (there is not tarball for upstream's git master branch updated daily)
[21:49] <landrover> I am referring to https://help.launchpad.net/Packaging/SourceBuilds/Recipes
[22:09] <wgrant> cody-somerville: Sources with NBS binaries will continue to show up on +delete-packages, or the binaries can be removed through the API.
[23:19] <hallyn> FEH.  i should check topic here more often
[23:20] <nhandler> Hmm...I just tried using the +contactuser page to send a user a message. I get an info box below the one about the maintenance box saying my message was sent. However, I also see a "Sorry, you can't do this right now" message. Was my email sent?
[23:27] <wgrant> nhandler: That's a good question. I wouldn't think so (mail sending is tied to the transaction, and committing that would have failed).
[23:27] <wgrant> But I don't know for sure.