[05:20] <thomi> Does anyone know why there is such a large disparity between the time for a source package to be built and a binary package to be built on launchpad right now?
[05:21] <thomi> I'm seeing 3 minutes vs 3 hours...
[05:21] <wgrant> thomi: Source package recipes only build on i386. It's possible that there is a large i386 queue at the moment.
[05:22] <wgrant> Hmm, we're running perilously low on builders at the moment.
[05:22] <thomi> ahh I see, so the source packages can be built on any machine, right?
[05:22] <wgrant> Yes, but at the moment they only build on i386 (it simplifies things a lot, and it's normally not a problem)
[05:23] <wgrant> Most of the builders have been taken for natty testing. I'll try to shuffle the remaining ones around to even up the queues, but it's not going to be good until they return (probably in several hours)
[05:24] <thomi> ahh ok, the official distro packages are built on these machines? That would explain why they're kind of busy right about now ;)
[05:25] <wgrant> Ubuntu itself builds on a separate set of machines. But most of the PPA builders serve a second role: hardware testing.
[05:28] <thomi> ahh, ok, cool.
[08:05] <happyaron> This buildjob seems to have some trouble: https://launchpad.net/~happyaron/+archive/kernel/+buildjob/2481761
[08:07] <happyaron> maybe a buildd admin should cancle it...
[08:07] <jussi> Hrm, is it possible for companies to use LP for closed source bug tracking?
[08:10] <happyaron> wgrant: ping?
[08:12] <wgrant> jussi: Yes. See https://launchpad.net/+tour/join-launchpad#commercial.
[08:14] <wgrant> happyaron: I've killed it.
[08:14] <happyaron> wgrant: thanks
[08:14] <happyaron> wgrant: it restarts...
[08:15] <wgrant> happyaron: Yeah. Should it not?
[08:16] <happyaron> wgrant: not sure, the amd64 build was failed, and i386 build keep running with no hint to stop - while in the ubuntu archive it build successfully.
[08:16] <wgrant> happyaron: Probably a glitch on the builder. This one will hopefully succeed.
[08:18] <happyaron> wgrant: OK, I'll monitor it. If something still goes wrong then I'll be here to ping you again. Thanks.
[08:18] <wgrant> Great.
[08:52] <progfou> hi there! anyone to guide me about a git import problem in Launchpad?
[08:53] <lifeless> hi, just ask
[08:53] <progfou> Import failed with this message: The repository you are fetching from contains submodules. To continue, upgrade your Bazaar repository to a format that supports nested trees, such as 'development-subtree'.
[08:53] <progfou> see: http://launchpadlibrarian.net/69776884/b2uconverter-b2uconverter-trunk.log
[08:54] <progfou> I know I have multiple branches in this git repository, but on the VcsImports wiki page it is said it would only import the master branch, right?
[08:54] <progfou> the HEAD branch in fact… see https://help.launchpad.net/VcsImports
[08:55] <progfou> is there something I can do on my side to go further?
[08:55] <lifeless> ok, so thats submodules, not multiple branches issue
[08:55] <lifeless> or are you saying that HEAD does not use submodules?
[08:55] <progfou> well… I don't know about submodules…
[08:56] <progfou> you can see the git repository here: http://git.hanoilug.org/?p=b2uconverter.git;a=summary
[08:56] <progfou> we have branches, tags, and nothing more as far as I can tell
[08:58] <lifeless> http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html
[08:58] <lifeless> has info about submodules
[08:58] <lifeless> we can't import them (yet).
[08:59] <progfou> thanks, I was just googling it… ;-)
[09:02] <progfou> ok, I'm checking my git repository if there is some submodmules put in place by default (by gitosis or else), since I never used that before… I'll be back in a few minutes
[09:06] <progfou> no result for "git submodule status" or "git submodule summary", as well as a "grep -r module ." just after a "git clone"… lifeless, do you have some other test suggestion?
[09:07] <progfou> I'll try a bare clone… and check in the gitosis bare repository too…
[09:08] <lifeless> I'm not surel; it sounds like either the detection code is broken or something else is up
[09:08] <lifeless> jelmer_: ^ any thoughts
[09:10] <progfou> nothing (no "module" config) in a "git clone --mirror" (imply --bare) either
[09:38] <progfou> I have to go work on other projects now, I'll come back to check this one later… anyway, thanks lifeless for your answers :)
[09:40] <progfou> BTW, just saw that on identi.ca: launchpadstatus: Codehosting upgrade completed; thanks for your patience - we hope to make renaming branches much more robust shortly thanks to this
[09:40] <progfou> not sure if it is related though…
[09:40] <lifeless> not relted
[09:41] <progfou> it is related to bazaar code hosting, right?
[09:41] <wgrant> progfou: Yes, it's about that service.
[09:41] <wgrant> But it didn't affect code imports.
[09:41] <progfou> ok
[09:41] <progfou> thanks
[10:07] <poolie> roughly how long is the delay from a binary build succeeding to the results being available in the archive?
[10:07] <lifeless> depends on the archive
[10:08] <lifeless> ppas run at a higher frequency than Ubuntu itself
[10:14] <wgrant> poolie: In the primary archive it can take nearly two hours if you're really badly timed.
[10:14] <wgrant> poolie: For PPAs it should be within 10 minutes, normally within 5.
[10:38] <maxb> I seem to be experiencing missing sprites on Launchpad. Is natty's firefox incompatible with the placement trickery?
[10:38] <maxb> Same symptoms on prod/edge/staging/qastaging/dogfood, so it can't be a recent code change
[10:41] <lifeless> maxb: there is a bug about the png layout triggering pathological render times
[10:41] <lifeless> maxb: and another one about the sprints now showing in konq
[10:42] <lifeless> *sprites(
[10:42] <maxb> I don't see performance issues - just absent sprites
[10:44] <wgrant> maxb: Hm, interesting, I was blaming that on fglrx being crap.
[10:45] <maxb> ahhhh
[10:45] <wgrant> maxb: Works fine in Chromium, but breaks in Firefox 4.
[10:45] <maxb> that could explain it
[10:45] <wgrant> A similar thing happened a couple of years ago.
[10:45] <wgrant> Are you fglrx too?
[10:45] <maxb> I recently switched from radeon to fglrx because I was fed up with radeon hiding my mouse pointer in a strip down the edge of one of my monitors
[10:46] <wgrant> Back before fglrx broke in natty (last year some time) the sprites appeared to be uninitialised memory.
[10:46] <wgrant> now they're mostly not there at all.
[10:49] <hjd> (Sorry for repeating myself, but it seems to be a bit more activity here today) Are there any known issues concerning converting bug status from Debian to Launchpad? See last comment on bug 656476.
[11:01] <wgrant> hjd: It was previously Unknown, so it had not scanned before. The Debian bug is tagged 'pending', which generally means that an upload is imminent, which translates to Launchpad's Fix Committed status.
[11:05] <hjd> wgrant: ok, so it's intended behaviour?
[11:08] <wgrant> hjd: Yes. But the 'pending' tag has been on the Debian bug for months :/ That's not meant to happen.
[11:13] <hjd> wgrant: thanks :) I left a short comment on the bug.
[12:26] <rhce7320> hello.  Is the the channel to talk translations?
[12:29] <rhce7320> I have a Zambian friend whom I have got interested in starting a translation effort for Bemba.  Bemba is the most common 1st language in Zam (English is 2nd) & SE Congo.  I would appreciate any help/advice in how to get her started.
[12:33] <progfou> the first step is to get this language available as a choice
[12:34] <progfou> and from what I can see in ISO 639 files, the Bemba language code should be "bem"
[12:34] <wgrant> Launchpad already supports Bemba (language code 'bem')
[12:34] <wgrant> Heh.
[12:34] <wgrant> I don't believe there's a translation team for it, though.
[12:35] <wgrant> rhce7320: https://wiki.ubuntu.com/Translations may be a good start. It has some howtoish links down the bottom.
[12:36] <progfou> take care to not mistake "bem" = Bemba for Zambia and "bmy" = Bemba for DR Congo
[12:37] <wgrant> They have different lang codes? :/
[12:37] <wgrant> We only have bem.
[12:37] <progfou> it seems so, at least in the ISO 639-3 available from /usr/share/xml/iso-codes/iso_639_3.xml
[12:38] <wgrant> Yeah.
[12:42] <rhce7320> Thankyou for the pointers. I'll digest the wiki. :)
[12:47]  * popey tickles mpt 
[12:47] <mpt> hmm?
[13:51] <happyaron> wgrant: the build behaves correctly this time (fail as amd64, which might be a backport issue), thanks!
[14:48] <diwic> jelmer, do you have time for some brainstorming?
[14:49] <jelmer> diwic: hi
[14:49] <jelmer> diwic: what bout?
[14:49] <jelmer> diwic: what about?
[14:50] <diwic> jelmer, well, if you remember my giant sound-2.6 kernel tree, I wonder if we can make it smaller at import time
[14:50] <diwic> jelmer, because I have discovered yet another problem with it (I believe)
[14:51] <jelmer> diwic: during the import from git you mean?
[14:51] <diwic> jelmer, https://code.launchpad.net/~diwic/sound-2.6/trunk - the import succeeds, but LP gets stuck in "updating branch...", which I suspect causes the daily recipe build not to be triggered
[14:52] <diwic> jelmer, yeah
[14:52] <jelmer> diwic: I don't think that has anything to do with the size of the branch
[14:52] <jelmer> jcsackett: hi
[14:52] <jelmer> jcsackett: do you know if something is up with the branch scanner?
[14:53] <wgrant> SOme branches are stuck after the network incident last week, but that's not the issue with this one.
[14:54] <diwic> wgrant, agreed - this one is stuck since 2011-03-25
[14:54] <jcsackett> jelmer: we did a codehosting update about 8 hours ago; pushing and pulling was offline for a few minutes, and there were bzrssh bumps.
[14:54] <jcsackett> jelmer: beyond that, nothing i know of off the top of my head. doesn't sound related.
[14:55] <diwic> jcsackett, that's probably not it - this one has been stuck for a while
[14:55] <jcsackett> diwic: yeah, that's why i assume no relation.
[14:56] <diwic> jcsackett, the correlation I see is that when I see when my recipe auto-built last time was 2011-03-25, which is the same date as the top date listed in the history of https://code.launchpad.net/~diwic/sound-2.6/trunk
[14:57] <wgrant> diwic: The scanner appears to not like your branch at all.
[14:58] <wgrant> In that it hangs for 20 minutes and dies.
[14:58] <wgrant> This is less than optimal.
[14:59] <jelmer> other linux trees (e.g. lp:linux) seem to work fine, which makes me think it's unrelated to the size
[15:00] <wgrant> jelmer: Well, 'fine'.
[15:00] <wgrant> jelmer: linux regular OOMs the branch mail job runner.
[15:00] <wgrant> regularly.
[15:00] <jelmer> wgrant: oh, whoa
[15:00] <jelmer> is the branch mail job runner an independent thing or part of the branch scanner?
[15:01] <wgrant> jelmer: It has a separate OOPS prefix.
[15:01] <diwic> wgrant, hmm, which kind of brings me back to the original question about whether we can make it smaller at import time (e g by skipping either some history or some subdirectories)
[15:01] <jelmer> wgrant: I'm also a bit surprised the branch scanner takes 20m on this branch - if it knows the previous tip it should only have to process a fraction of the revisions
[15:02] <wgrant> jelmer: That's what you'd think...
[15:02] <jelmer> diwic: you could set up a cron script that strips out some history/subdirectories using fastimport/fastexport
[15:02] <deryck> Orange Squad is the help this week, yo! :-)
[15:02] <wgrant> I may play with it locally/staging tomorrow.
[15:02] <wgrant> deryck: Huh?
[15:02] <wgrant> deryck: When did that happen?
[15:02] <deryck> just now
[15:02] <wgrant> jelmer: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1920BM1
[15:02] <deryck> wgrant, you are the first to be told :-)
[15:02] <wgrant> deryck: Ah, congrats. Welcome to Critical land :(
[15:02] <deryck> wgrant, thanks!  I fear no bug! :-)
[15:03] <diwic> jelmer, now you're talking - what machine should I run that script on?
[15:03] <wgrant> deryck: With the extra people we should be able to make good progress :)
[15:04] <jcsackett> deryck: you have no idea how happy we are to have another squad on deck. :-)
[15:04] <wgrant> Ooh yes.
[15:04] <deryck> wgrant, yeah, I hope so.  we still have to close a couple wip bugs, but were doing duties like irc until those close.
[15:04] <wgrant> Great.
[15:04] <deryck> jcsackett, I hear that :-)  Sorry you guys had to go it alone so long.
[15:04] <jcsackett> deryck: s'all good.
[15:04] <wgrant> This means we have European coverage now too! Yay.
[15:04] <jelmer> diwic: it wouldn't be on Launchpad itself, the vcs imports only support full-tree imports (neither bzr nor git do partial checkouts)
[15:05] <jcsackett> deryck: we have found that the maintenance rotation stuff is still a work in progress. sinzui made a bunch of fixes on the wiki describing the work, but if you find anything needing clarification or stuff that works better, by all means update. the process is not set in stone by a long shot. :-)
[15:05] <deryck> jcsackett, gotchas.  I plan to chat with sinzui about it all too when he's around.
[15:06] <jcsackett> dig.
[15:06] <deryck> orange may be slow for the first day or two, but we'll catch on and hit hard along side you guys.
[15:19] <jjardon> Hi, currently lp:glib points to ~jjardon/glib/trunk instead ~vcs-imports/glib/trunk , how Can I fix this?
[15:19] <deryck> hi jjardon.  let me take a look....
[15:27] <deryck> jjardon, looking into.  I can change it for you, but it errors on the branch name.  You have a link for the branch?
[15:27] <deryck> jjardon, the branch you want lp:glib point at?
[15:28] <deryck> ah, found it, I think.  jjardon -- ~vcs-imports/glib/head ?
[15:28] <jjardon> deryck: yeah, I think makes more sense
[15:28] <jjardon> than in my local domain
[15:29] <deryck> jjardon, done
[15:30] <deryck> jjardon, I don't know why you can't change this since you're maintainer.  I can look into it.
[15:31] <deryck> maybe jcsackett knows that black magic.  Can maintainers not change series focus branch?  see ^^
[15:32] <jjardon> deryck: thanks!
[15:37] <jcsackett> deryck: i don't know off the top of my head. seems worth investigating though.
[15:38] <deryck> jcsackett, ok, I'll look into it further.
[15:38] <jcsackett> deryck: if currently they can't, i think we can make a strong case for changing that.
[15:39] <deryck> jcsackett, yeah, that would be my guess, is just they don't have permission to do so.  But seems odd to me.
[15:39] <jcsackett> deryck: agreed. it's weird.
[16:56] <X-Or> Hello
[16:56] <X-Or> A question about Subversion imports into launchpad,
[16:56] <X-Or> Does LP allows to import trunk or just branchs ?
[17:11] <pfarrell_> hi
[17:12] <pfarrell_> I have a branch, ~pefarrell/fluidity/adjoint. I'd like to give user simon-funke write access to that branch. how do I do it?
[17:12] <pfarrell_> (sorry, I am new to launchpad)
[17:21] <bigjools> you need to make it owned by a team that you're both in
[17:37] <deryck> X-Or, isn't trunk the same as a branch in svn?  Or what do you mean?
[17:48] <X-Or> It is 2 different things
[17:56] <deryck> X-Or, I know we import svn "trunk" all the time for projects on Launchpad.
[17:56] <deryck> X-Or, I always thought this was a naming convention for svn, and nothing special.
[18:04]  * deryck reboots and will brb
[18:22] <SMG> I know this is not the place, but running out of options " can someone help me, i need to update the "ar" file under "binutils", because it causes "*** buffer overflow detected ***: ar terminated" while compiling anything, but I cant update binutils because of the same problem?"
[18:37] <SMG> hello, can someone help
[18:58] <deryck> SMG: hi, yeah, sorry, this isn't the place for that. I'm not sure where to point you.... thinking....
[18:59] <deryck> SMG: is this binutils in Ubuntu?
[18:59] <SMG> deryck:yes
[19:00] <SMG> deryck:i think i might have to reinstall, which is what im trying to avoid
[19:00] <deryck> SMG: so I would suggest asking where to ask for help on #ubuntu.  Or filing a question against binutils in Launchpad:  https://answers.launchpad.net/ubuntu/+source/binutils
[21:45] <bdrung> hi, i have a problem with an recipe: https://launchpadlibrarian.net/69841782/buildlog.txt.gz
[21:46] <bdrung> "Source repository format does not support stacking, using format"
[21:46] <bdrung> how can i fix it?
[21:46] <bdrung> the branch in question: https://code.launchpad.net/~vcs-imports/devscripts/main
[21:56] <bdrung> sorry, the problem lies somewhere else (outdated branch).