[00:22] <micahg> are bugs not being able to pull status form upstream trackers a known issue?
[00:23] <wgrant> micahg: Which tracker?
[00:23] <wgrant> I know of an issue with debbugs.
[00:23] <micahg> wgrant: I just saw it for mozilla on bug 569528,but have seen it for gnome and debian
[00:24] <micahg> oops
[00:24] <micahg> bug 588595
[04:02] <brr> One of the PPA build machines got stuck: https://launchpad.net/builders/terranova
[04:44] <d1b> OH HAI
[04:44] <d1b> question why do i see in my bug reports listing duplicates of some bugs?
[04:45] <d1b> is this because it is tagged for different distros?
[04:45] <beuno> d1b, because they have multiple targets, yes
[04:45] <lifeless> if you're searching in a context that can have multiple tasks, yes.
[04:45] <lifeless> its a feature; the ui can be improved
[04:45] <d1b> right and there isn't an option to change that?
[04:45] <beuno> well, this is for his personal list I assume
[04:45] <d1b> yeah :)
[04:45] <lifeless> I was chatting with deryck about that a couple weeks back, not on the roadmap immediately
[04:45] <beuno> its a bug, just a hard one to solve
[04:45] <d1b> beuno: oh hardly ;)
[04:46] <d1b> select * from bugs where ....
[04:46] <lifeless> d1b: its strictly correct, because it shows the *target* column.
[04:46] <lifeless> d1b: select DISTINCT is needed, but these results *are* distinct.
[04:46] <lifeless> what I think would be nice would be to show all the targets as one row
[04:46] <lifeless> with something nice breaking out the status per target
[04:47] <d1b> lifeless: don't include anything but the bug number for the distrinc ;)
[04:47] <beuno> right, its a UI issue rather than technical
[04:47] <d1b> yeah :)
[04:47]  * beuno has discussed multiple times
[04:47] <lifeless> d1b: if we did that, today, it would not show some tasks (because it shows one task per row). That would be worse.
[04:47] <d1b> right. why not just put them in a sort of larger row if that is the case
[04:48] <lifeless> d1b: isn't that what I just said I would like to see?
[04:48] <d1b> lifeless: don't nkow what you asid :)
[04:48] <lifeless> look up above
[04:48] <d1b> oh ah no sort of
[04:48] <beuno> one of the problems is that each bugtask can have a different importance
[04:48] <d1b> show the targets sure -but if the status differs show that too
[04:48] <beuno> and default sorting isby importance
[04:48] <beuno> so it makes it hard to decide where to plate it
[04:49] <d1b> give it the highest importance assigned to the bug number# regardless of target?
[04:49] <lifeless> beuno: move it around as the users eyes cross
[04:49] <d1b> haahahah
[04:49] <lifeless> beuno: different areas of the screen
[04:50] <beuno> oh, life would get very intersting if we could know where people's eyes are going  :)
[04:50] <lifeless> beuno: appropriately pretty models of the appropriate gender can control that :P
[04:51] <beuno> heh
[04:52] <beuno> it's amazing when you see the eye-tracking software show you how people's eyes go straight to people's exposed areas on ads, no matter how much people try
[04:52] <d1b> so just reuse some of the old ubuntu material then ;)
[04:52] <lifeless> beuno: its how we got here .... really not surprising
[04:56] <beuno> lifeless, what was surprising is that the first look is *always* at the eyes
[04:56] <d1b> big brother is following you!
[04:57] <d1b>  http://www.hughsandeman.co.uk/media/blogs/archive/bigbrother.JPG
[04:58] <lifeless> beuno: I wonder if its worth doing a little (v) and (^) on duplicate results
[04:58] <lifeless> beuno: labelled 'next task of this bug'
[04:58] <lifeless> beuno: duplicate results being the wrong thing to say, of course. But you know what I mean.
[04:59] <lifeless> beuno: so with three tasks, the first shown would have
[04:59] <lifeless> v
[04:59] <lifeless> the second
[04:59] <lifeless> v^
[04:59] <lifeless> the third
[04:59] <lifeless> ^
[04:59] <beuno> yeah, the problem always comes back to which one to show first
[04:59] <lifeless> beuno: but this means you don't are
[04:59] <lifeless> *care*
[04:59] <lifeless> beuno: because it wouldn't be grouping them, there is no tension with sorting
[05:00] <lifeless> some query magic needed still to determine next/prev on this page/not on this page.
[05:00] <beuno> lifeless, you still need to sort it some place one the list though
[05:00] <lifeless> but it at least has a clear behaviour
[05:00] <beuno> and choose which one to show first
[05:00] <lifeless> beuno: you place them all on the list
[05:00] <beuno> no?
[05:00] <lifeless> beuno: exactly as they are today
[05:01] <lifeless> beuno: just add a really small tasteful link to the next/prev tasks of that bug beside the bug target
[05:02] <beuno> lifeless, I don't follow. You still show all 3 of them?
[05:02] <beuno> or you show 1 row, with prev/next
[05:03] <beuno> I am looking at: https://bugs.edge.launchpad.net/~beuno
[05:04] <beuno> the "In" column is the target
[05:04] <lifeless> all hree
[05:05] <lifeless> or you could show a + or something with a popup that lists all the tasks (and still show each task as separate rows
[05:05] <beuno> I see, just so you could visualize it better?
[05:05] <lifeless> beuno: I'm saying, don't mess with the table. Annotate the rows that have the same bugid in some way to make the duplication self documenting and explicator
[05:06] <lifeless> y
[05:06] <beuno> gothca
[05:06] <lifeless> mmm goth
[05:06] <beuno> so it wouldn't really solve this dupe-look-a-like issue
[05:06] <beuno> it may make it feel worst
[05:06] <beuno> but it will explain better what's going on
[05:06] <beuno> it's a nice step forward I think
[05:08] <beuno> lifeless, something else we could fiddle with, is moving the target next to the bug #
[05:09] <beuno> so people understand this relatonship better
[05:09] <lifeless> perhaps visually group somehow ?
[05:09] <lifeless> like with a slightly darker border athe outer edge of their two rows
[05:10] <beuno> yeah, something like that
[05:10] <lifeless> beuno: that would be nice too
[05:10] <lifeless> where is the bug to write this stuff up in
[05:13] <beuno> lifeless, bug 1357 no less!
[05:13] <beuno> 4 digit bug!
[05:13] <lifeless> \o/
[05:13] <lifeless> beuno: would you like the honours ?
[05:13] <beuno> oh sure, why not
[05:14] <beuno> haven't done this in a while, I'm nervous!
[05:14] <lifeless> ha!
[05:19]  * beuno comments
[05:24] <beuno> lifeless, off to bed. Nice talking UI and Launchpad to you again!
[05:24] <lifeless> beuno: likewise, sleep well!
[05:24]  * beuno waves
[05:32] <nhaines> beuno: good night!  :)
[09:10] <dobedobedoh> What's the best way of requesting a feature/change to Launchpad?
[09:10] <dobedobedoh> At present, Launchpad links to bugs if a comment fits a syntax like bug #xxxxx
[09:10] <poolie> dobedobedoh: file a bug in https://launchpad.net/launchpad, or ask here
[09:11] <poolie> ok
[09:11] <dobedobedoh> It would be quite handy if it also recognised something like (Closes: #xxxxxx)
[09:11] <dobedobedoh> As per the debian devleoper reference
[09:11] <poolie> i would kind of expect that to also actually close the bug
[09:11] <poolie> i think it does match that in commit messages?
[09:12] <poolie> actually isn't the debian standard to say "LP: #1", to distinguish it from debbugs?
[09:12] <dobedobedoh> haven't seen it match in commit messages yet
[09:12] <wgrant> (Closes: #XXXXXX) is Debian-specific.
[09:13] <wgrant> The Launchpad equivalent is LP: #XXXXXX, as poolie says.
[09:13] <wgrant> (Closes: #XXXXXX) could perhaps link to the relevant Debian bug.
[09:13] <dobedobedoh> Okay - fair enough
[09:17] <dobedobedoh> There was another question I had - when adding comments, is there any markdown or other syntax highlighting?
[09:17] <dobedobedoh> Or handy way of posting a log excerpt without having it line wrapped?
[09:44] <marktheunissen> hi all!
[09:44] <marktheunissen> help! we need to deploy code urgently and launchpad is down. :<
[09:45] <marktheunissen> anyone know what the ETA for loggerhead coming back is?
[09:46] <LinuxJedi> marktheunissen: see topic :)
[09:47] <marktheunissen> ah gotcha
[09:47]  * LinuxJedi was trying to look into code on lp to fix some valgrind warnings when it happened ;)
[09:48] <harpreet> Hi everyone
[09:49] <harpreet> Is this correct place for asking questions about vmbuilder on ubuntu.
[09:58] <marktheunissen> hmm, seems to be back?
[09:58] <marktheunissen> is it safe to user?
[09:58] <marktheunissen> *user
[09:58] <marktheunissen> *use
[11:26] <hrw> hi
[11:26] <hrw> how can I clean PPA's APT archive from packages?
[11:27] <hrw> bumping versions is not possible
[11:27] <bigjools> I think Ubuntu has a downgrade script somewhere
[11:27] <bigjools> I've not used it myself
[11:27] <bigjools> try asking in #ubuntu
[11:27] <hrw> ok
[11:29] <hrw> Ubuntu has ppa-purge but it removes PPA's packages from system. I want to remove packages from APT archive of my PPA.
[11:30] <bigjools> hrw: just delete them
[11:31] <hrw> how much time it takes between "packaged deleted" LP message and getting them removed?
[11:32] <hrw> ok, done
[11:32] <hrw> thx
[11:32] <hrw> now need to reupload my source
[11:32] <bigjools> it takes up to about 15 minutes sometimes
[11:33] <bigjools> you can't re-upload the same version
[11:33] <bigjools> you must bump it
[11:33] <hrw> even when I deleted it from LP?
[11:33] <bigjools> I see what you mean in your original question now
[11:33] <bigjools> yes, even when you delete it
[11:33] <bigjools> https://answers.edge.launchpad.net/soyuz/+faq/990
[11:33] <hrw> ok, will bump then
[12:21] <Odd_Bloke> I'm having yet more problems related to my emails.  The latest commit at https://code.launchpad.net/~daniel-watkins-credativ/openobject-addons/crm_max_fix is by "Daniel Watkins <daniel.watkins@credativ.co.uk>", which is related to ~daniel-watkins-credativ.  However, the link on that page points to ~daniel-thewatkins, which is no longer associated with the email.
[12:21] <Odd_Bloke> Is there anyone available to have a poke and work out what's going on?
[12:37] <LinuxJedi> Odd_Bloke: who are you logged in as in "bzr launchpad-login"?
[12:38] <LinuxJedi> (executing that will show you)
[12:44] <Odd_Bloke> LinuxJedi: daniel-watkins-credativ
[12:48] <LinuxJedi> Odd_Bloke: hmm... really odd, maybe its something to do with the ssh keys used
[13:03] <wgrant> Odd_Bloke: Commit authors are tracked as a separate mapping from email addresses to users.
[13:03] <wgrant> I don't know of a way to get them moved across.
[13:04] <Odd_Bloke> :(
[13:04] <Odd_Bloke> Shall I file a bug/question or something?
[13:05] <wgrant> A question, perhaps.
[13:08] <dholbach> hiya
[13:09] <dholbach> could I interest anybody in sharing their wisdom about using bzr, launchpad, code reviews, launchpadlib, hacking in a nice way or any other app development related topic at Ubuntu App Developer Week? :-)
[13:11] <Odd_Bloke> https://answers.launchpad.net/launchpad-code/+question/123948 filed.
[14:26] <hrw> http://launchpadlibrarian.net/54867642/buildlog_ubuntu-maverick-amd64.armel-cross-toolchain_1.28_FAILEDTOBUILD.txt.gz shows that libc6-armel-cross is not available. But this package is present in this PPA APT archive... what is wrong?
[14:28] <bigjools> hrw: remind me of your PPA url again?
[14:28] <hrw> https://edge.launchpad.net/~hrw/+archive/arm-cross-compiler/+build/1945328
[14:31] <bigjools> hrw: libc6-armel-cross might not be installable for some reason, does it have all its dependencies available?
[14:31] <hrw> rechecking now
[14:34] <hrw> installed fine
[14:34] <hrw> directly from ppa
[14:35] <bigjools> can you retry the build please
[14:35] <hrw> sure
[14:35] <bigjools> it may not have been published in time
[14:35] <thopiekar> hi
[14:35] <thopiekar> is it possible to comment out a line in a recipe?
[14:58] <hrw> bigjools: same
[15:02] <bigjools> hrw: the queue is quite big, your build won't have finished yet?
[15:02] <hrw> it failed already
[15:03] <hrw> https://edge.launchpad.net/~hrw/+archive/arm-cross-compiler/+build/1945391
[15:04] <bigjools> you uploaded a new version?
[15:05] <hrw> yes
[15:06] <bigjools> you can just retry the original if it failed
[15:06] <hrw> new ver is same just version bumped
[15:07] <bigjools> I realise - I'm just saying you don't need to do that to retry a failed build
[15:07] <hrw> ah, did not know
[15:13] <bigjools> I am doing a test installation here
[15:16] <bigjools> hrw: ok so libc6-armel-cross depends on libgcc1-armel-cross which depends on gcc-4.5-arm-linux-gnueabi-base which does not exist
[15:16] <bigjools> you can use the "chdist" tool to work this out BTW
[15:18] <hrw> sorry then
[15:18] <hrw> too much builds of the same
[15:22] <hrw> ok, another 1.5h of builds to wait (+ queue)
[16:35] <hrw> I have 1.35 in PPA which just started building and 1.36 freshly uplaoded which fix bug in 1.35. will 1.35 build be killed with new upload or not?
[16:36] <bigjools> hrw: if it already started, no
[16:37] <bigjools> hrw: can I suggest that you use pbuilder locally to test your builds
[16:37] <bigjools> PPAs are not a build testing service
[16:38] <hrw> I do also in pbuilder - just it passed in it as it builds arch+all
[16:43] <hrw> thanks for all help bigjools and have a nice weekend
[16:43] <bigjools> hrw: no problem
[16:43] <bigjools> and thanks
[16:44] <nessita> abentley: ping
[16:44] <abentley> nessita, hi.
[16:44] <nessita> abentley: good morning! would you have some minutes to talk about a possible issue with lp:ubuntuone-client code? beuno suggested that you may help us
[16:45] <nessita> abentley: basicaly, https://code.launchpad.net/ubuntuone-client is reporting that latest version of trunk is 627
[16:45] <nessita> abentley: and in our local copies of trunk we have upto revno 671
[16:45] <abentley> Okay.
[16:45] <nessita> abentley: revno 627 was landed on 2010-08-11
[16:46] <abentley> nessita, actually, I see 627 just landed.
[16:46] <nessita> abentley: LP is sayins "21 hours ago" for revno 627
[16:47] <abentley> nessita, Sorry, meant to type 628.
[16:48] <abentley> nessita, which landed 10 minutes ago.
[16:48] <nessita> abentley: yes, that was tarmac that is running in a cron job
[16:48] <nessita> abentley: we already disabled
[16:49] <nessita> abentley: the problem is that upto yesterday trunk had 671 revnos
[16:49] <nessita> abentley: and today only to 627
[16:49] <nessita> abentley: and besides the revno numbers mismatch, the code for those revnos is gone as well (I know we can recover that, but we'd like to diagnose what happened)
[16:49] <abentley> nessita, what do you see if you do "bzr missing" with a local copy against trunk?
[16:50] <nessita> abentley: running the command right now
[16:51] <nessita> abentley: http://pastebin.ubuntu.com/
[16:51] <nessita> oops
[16:51] <nessita> http://pastebin.ubuntu.com/487870/
[16:53] <abentley> nessita, it looks like facundo@taniquetil.com.ar had revno 627, merged 671, committed and pushed.
[16:54] <nessita> abentley: that's for revno 628 right?
[16:55] <abentley> nessita, yes.  But actually that was committed and pushed by tarmac?
[16:55] <nessita> abentley: we should avoid looking at thta revno, it landed when trunk was already messed up
[16:55] <nessita> abentley: yes, we mostly land branches using tarmac
[16:55] <nessita> abentley: see this: https://pastebin.canonical.com/36736/ is the output of
[16:55] <nessita>  bzr log -r627..671 --show-ids
[16:56] <nessita> abentley: as you can see, there are all the missing revnos
[16:57] <abentley> hmm.  So it seems like the new revno 628 does include everything up to 671, or else bzr missing would have shown more.
[16:58] <nessita> abentley: maybe, I can do a recursive diff to check
[16:58] <abentley> nessita, I'm not aware of any way the revisions can be accidentally removed from the timeline.  It should only happen if you uncommit or push --overwrite.
[17:00] <nessita> abentley: I see. Can we know if that actually happened? because as far as we know we haven't pushed with --overwrite
[17:00] <nessita> abentley: we're really worried about this, and it would be very important to understand what happened
[17:01] <abentley> nessita, no, our server doesn't know what command is being run when a branch is changed.
[17:01] <abentley> nessita, rick mcbride is subscribed to revision notifications, so he should have been emailed when this happened.  Looks like no one else is subscribed.
[17:02] <nessita> abentley: I'll ask him, thanks. Just to be sure I understand, is there any chance that today's maintenance had something to do with this?
[17:02] <nessita> abentley: we land all the branches using tarmac, except for tags that we push "by hand"
[17:03] <abentley> nessita, I can't think of a way that it would be implicated.
[17:03] <nessita> is very, very unlikely that someone ran push --overwrite :-/
[17:04] <nessita> abentley: anyways, thanks a lot for your help, I'll try to find more info from rmcbride
[17:14] <rmcbride> nessita: just got back from retrieving lunch. I'll dig through the rev notifications
[17:15] <nessita> rmcbride: thanks!
[17:23] <nessita> abentley: so, can we disable the ability to do push --overwrite to a given project? or can we log that somehow? or at least what can we do today to be able to debug it tomorrow?
[17:30] <nessita> abentley: still around?
[18:09] <lucidfox> What's the bzr equivalent of "git remote add origin"?
[18:11] <james_w`> lucidfox: it might be bzr pull --remember
[18:11] <james_w`> though I don't really know what the effect of that git command would be
[18:12] <dob_> hello, i created a new ppa and uploaded my sources, the upload was successful, even as i did not add my pgp key to my profile. Then i added my key and dput tells me: Package has already been uploaded to ppa on ppa.launchpad.net. But nothing happens, i am waiting for about an hour..... Any ideas?
[18:14] <james_w`> dob_: run with --force
[18:14] <dob_> upload was successful
[18:15] <dob_> how long will i have to wait for the status information in my repo?
[18:16] <dob_> ah okay
[18:16] <dob_> now i got a email
[18:16] <dob_> that it's accepted
[18:17] <lucidfox> james_w`> ah right, bzr help push clarified the matters
[18:17] <dob_> hi thank you very much
[18:17] <dob_> It's now in my repository
[18:24] <abentley> nessita, back.
[18:29] <nessita> abentley: hello again!
[18:30] <nessita> abentley: my team and I were wondering, can we disable the ability to do push --overwrite to a given project? or can we log that somehow? or at least what can we do today to be able to debug it tomorrow?
[18:31] <nessita> abentley: rmcbride received an email, this morning saying that "44 revisions were removed from the branch."
[18:31] <abentley> nessita, that suggests it was a user-driven change, not a bug in the hosting code.
[18:32] <abentley> nessita, I don't think you can disable push --overwrite.  bzr generally trusts its user.
[18:32] <abentley> nessita, since you already have a bot managing the branch, why not make the bot the only one who can write to it?
[18:33] <abentley> nessita, this is what we do in Launchpad.
[18:33] <nessita> abentley: yes, we'll try that. Biut we al
[18:33] <nessita> oops, wrong enter
[18:34] <nessita> abentley: but we also need some sort of logging... can we do that? at least for pushes --overwrite? or to what command was used to push?
[18:35] <abentley> nessita, there is logging on the user side that would show this.  On the server side, we deal with lower-level primitives.
[18:36] <abentley> nessita, e.g. we know that a branch has changed from one revision-id to another, not that push was issued.
[18:37] <abentley> nessita, and if sftp is used, we don't even know that.
[18:38] <nessita> abentley: ok then, thanks for your time
[18:40] <deryck> adeuring, you disappeared again
[18:41] <deryck> heh
[19:08] <EdwinGrubbs> does anybody know how long it will be before staging is up? It seems like it has been updating the code for the last four hours.
[19:45] <kirkland> just checking ... are you guys aware that the Google Maps API is busted?
[19:45] <kirkland> looks like the key is expired
[19:47] <deryck> hi kirkland.  yeah, we're aware.  Not sure what the state of our fix is, though I thought we had disabled the maps on edge now.
[19:50] <deryck> I think it's actually a change in Google's SSL support, not the key though.
[19:50] <deryck> sinzui knows all, I believe.
[19:52] <sinzui> I know nothing about a 10,000 SSL fee
[19:52] <sinzui> I am an engineer
[19:53] <deryck> heh
[20:43] <yofel> jelmer: anything needed for https://code.edge.launchpad.net/~neon/project-neon/ontologies to be approved? I'm not too familiar with setting up imports
[20:55] <jelmer> yofel, hi
[20:55] <jelmer> yofel, mainly for somebody in the vcs-imports team to approve the import
[20:56] <yofel> k, will wait then
[20:56] <jelmer> yofel: Looking at that import, I think it should be under the ontologies project on launchpad though
[20:56] <jelmer> rather than under project-neon
[20:57] <yofel> I don't think we have a project for that
[21:02] <smoser> how do i create a new spec (blueprint ) ?
[21:02] <smoser> i'm looking https://blueprints.launchpad.net/~smoser and i can't figure out how to add a new one.
[21:09] <annodomini> Is there a sample or sandbox project on Launchpad, that I could use for playing around with without spamming a real project?
[21:17] <smoser> i figured out my issue above.
[22:03] <popey> http://popey.com/~alan/aaaaaaargh.png etc
[22:03] <popey> trying to file a bug with apport on lucid, i get that.. is this a launchpad issue?
[22:03] <popey> (note: I can browser to lp on that machine fine)
[22:17] <lifeless> popey: that would appear to be a local issue; *or* something is buggered :P
[22:17] <lifeless> popey: can you see what name its trying to lookup (strace or something might help there)
[22:24] <popey> lifeless: http://popey.com/~alan/apport_trace.log
[22:25] <lifeless> popey: its firing off /usr/share/apport/apport-gtk
[22:26] <lifeless> you'll want follow-fork, and you can look in ityourself ;P
[22:26] <lifeless> just for for resolver calls
[22:26] <popey> message understood :D
[22:26]  * popey is not an strace expert
[22:26] <popey> thanks though :)
[22:28] <lifeless> popey: I have a few things to do here like checking for earthquake damage ;P
[22:28] <lifeless> or I would be willing to read through the MB's of data you'll be generating.
[22:29] <popey> fun!
[22:30] <lifeless> we're in rangiora http://www.geonet.org.nz/earthquake/quakes/3366241g-maps.html
[22:31] <lifeless> http://www.stuff.co.nz/the-press/news/4094979/Huge-earthquake-rocks-Christchurch
[23:28] <mlaci> hi guys! can i hope that the timeout error goes away from this page anytime soon? - https://launchpad.net/~chromium-daily/+archive/ppa/+packages?field.name_filter=&field.status_filter=&field.series_filter=
[23:50] <lifeless> mlaci: what OOPS ID did you get
[23:50] <lifeless> !oops