[01:52] <idnar> bleh, just got a timeout trying to create a project
[01:52] <idnar> wait, no
[01:52] <idnar> the timeout was just loading the project page after it was created, nevermind
[01:53] <wgrant_> That's still very odd. Do you have an OOPS ID?
[01:53] <idnar> OOPS-2059DW4
[01:54] <wgrant> Thanks.
[01:54] <idnar> URL was https://launchpad.net/mantissa
[01:54] <idnar> (although I guess that's probably in the OOPS info anyway?)
[01:54] <wgrant> I think I might know what it is, but we'll see shortly...
[01:54] <wgrant> Yup.
[01:55] <wgrant> Yeah, 8.5s query trying to guess at possibly relevant source packages...
[01:55] <wgrant> There's a bug for that.
[01:55] <wgrant> Bug #739051
[01:56] <nigelb> wow, that's a very complicated bug to rread.
[01:57] <nigelb> *read
[01:57] <wgrant> Heh.
[01:57] <wgrant> lifeless has that effect on people.
[01:57] <wgrant> er, bugs.
[01:57] <nigelb> Haha
[01:58] <idnar> haha
[01:58] <nigelb> which bit is timing out? the source distribution bits?
[01:59] <wgrant> Yeah. It's the fti/ILIKE stuff.
[01:59] <nigelb> Lets make everything XHR! :)
[02:29] <lifeless> wgrant: nigelb: it is however suitable for an engineer to work on :)
[02:33] <nigelb> lifeless: Hah, ok I may have to agree there :)
[08:52] <sagaci> Hi, I was just wondering if there was an option to sort translation page templates into a decreasing string like, ie. package with most untranslated strings at the start.
[12:42] <mfraz74> is it possible to use https://launchpad.net/ubuntu/+ppas to search for packages in a certain series?
[13:08] <jelmer> mfraz74: I don't think it's possible at the moment
[13:08] <mfraz74> jelmer: OK, but it would be a useful addition
[13:09] <jelmer> mfraz74: I agree; you're always welcome to file a wishlist bug against the Launchpad project for things like this
[13:15] <mfraz74> https://bugs.launchpad.net/launchpad/+bug/830519
[17:26] <hakermania> hello, i'd like to ask something about ppa's. Specifically I want to ask about this: https://help.launchpad.net/Packaging/PPA where it says 'Supported Series'. Does this changelog looks OK for lp?: http://paste.ubuntu.com/671779/
[17:27] <hakermania> err
[17:27] <hakermania> This changelog: http://paste.ubuntu.com/671780/
[17:29]  * tumbleweed would recommend adding a ~ppa1 because that's the version you want to use in Ubuntu, eventually (and you may want to do a few more PPA uploads before then)
[17:32] <hakermania> tumbleweed, what is a ~ppa1? And whenever I want can't I delete a ppa and upload another one?
[17:33] <tumbleweed> hakermania: something to append to the version: 2.1-0ubuntu1~ppa1 No you can't re-upload the same version again, ever
[17:34] <hakermania> tumbleweed, Can't I do tests? To see how it works?
[17:34] <hakermania> Ok i see
[17:35] <directhex> did we confirm that rothera and vernadsky are running a Lucid 2.6.32 kernel?
[17:35] <directhex> we've isolated the mono build problem to an issue with EPOLL that only happens on those boxes
[17:37] <elmo> directhex: they're running hardy, not lucid
[17:37] <nigelb> directhex: Testing mono builds on lucid host was the first time I got a "sad" reply to "build success!" :)
[17:38] <hakermania> tumbleweed, how do I append the ~ppa1 after the 0ubuntu1 before building(so when building to generate 0ubuntu1~ppa1 files? I tried changing the changelog but it outputs errors.
[17:38] <directhex> elmo, ah. which kernel is that?
[17:39] <tumbleweed> hakermania: yes, you change the changelog, Read the errors, they may be helpful
[17:39] <directhex> 2.6.24. hm
[17:40] <directhex> nigelb, yeah :/
[17:40] <directhex> elmo, and the same applies for roseapple, which built okay?
[17:40] <elmo> directhex: all the buildds are still hardy, AFAIK
[17:40] <elmo> directhex: roseapple is on a slightly newer kernel
[17:42] <directhex> elmo, do we know how much newer? we've narrowed down the "bad" commit, but the issue of what triggers the problem is still open ended, since that "bad" commit still builds fine in most places
[17:44] <elmo> directhex: how about I just upgrade vernadsky + rothera to current?
[17:44] <elmo> and I'll file an RT about getting them all up-to-date (they should have been anyway - obviously)
[17:45] <directhex> elmo, if that works, then it means sweeping the epoll problem under a rug. which is kinda good enough, but feels like a cop-out. it'd certainly mean uploading new builds to oneiric stops being painful, i guess
[17:46] <elmo> directhex: if the bug is only present in obsolete versions of the hardy kernel, I don't see that as sweeping stuff under the rug
[17:46] <directhex> elmo, try it, i guess. ping me when it's updated, and i'll request a sync of 2.10.4-3
[17:46] <TheEvilPhoenix> its probably been fixed in later kernels, is my guess
[17:46] <elmo> (by the way, by current I mean current hardy - not lucid or something)
[17:46] <TheEvilPhoenix> mhm
[17:47] <elmo> an upgrade of the buildd farm as a while to a new distribution will need a lot more coordination with the release team and such
[17:47] <directhex> looks like the builders are mostly idle, so nobody should notice a reboot
[17:54] <elmo> directhex: done
[17:54] <directhex> that was quick
[17:55] <Laney> fancy taking one offline to test-rebuild mono in its chroot? :P
[17:55] <directhex> that'd be phenomenally useful, but i don;t know if it's possible :/
[17:56] <Laney> maybe elmo is feeling benevolent
[17:57] <elmo> Laney: sorry, I really don't have time, I'm running out of time to finish what I'm working on as it is - if that's the easiest way, you could file an RT, someone should be able to do it for you on Monday
[17:57] <Laney> fair enough
[17:57] <Laney> thanks for your help this far
[17:58] <Laney> it'll be easier to try a sync of -3 at that point (but you can bet it gets picked by roseapple)
[18:00] <elmo> well
[18:00] <elmo> that's easy to fix
[18:00] <elmo> I'll put roseapple into manual
[18:01] <elmo> done - all but rothera/vernadsky are in manual
[18:01] <elmo> if you can sync it now, go ahead - we'll wait it for to start building  then I'll unmanual the others
[18:01] <Laney> erm, it's not actually uploaded to debian yet
[18:02] <elmo> well, then I'll not do that..
[18:02] <Laney> sorry
[18:26] <propman> when i enter http://launchpadlibrarian.net my browser is just pointed to https:launchpad.net.   What is the correct method to view the files at http://launchpadlibrarian.net?   thanks :)
[18:26] <jelmer> propman: there are links on launchpad.net to them
[18:27] <jelmer> propman: there is no public index or anything like that for the librarian, it's just a file store used by launchpad
[18:28] <propman> jelmer: ahhh...ok thnak
[18:28] <propman> jelmer:  ok thanks.... :)  will have to do some wading through the site itself then.   much appreciated
[18:29] <jelmer> what are you looking for specifically?
[18:29] <propman> jelmer:  older linux kernels
[18:29] <jelmer> propman: just the tarballs, or packages?
[18:30] <propman> jelmer: probably packages would be best
[18:30] <jelmer> for the tarballs, kernel.org is probably a better place to look. For Ubuntu, see e.g. http://packages.ubuntu.com/linux
[18:31] <propman> jelmer:  ahhh...ok.   when googling, one of the references for them was launchpad but will check out the two you have sent too.   thanks again. :)
[19:46] <hakermania> Hello, I get this error: http://paste.ubuntu.com/671871/ And I cannot understand what's the solution of it, maybe because of the fact tham I'm not native english
[20:01] <hakermania> Will it disappear if I upload the 2.2 version or a ~ppa2?
[20:03] <tumbleweed> hakermania: it's saying you changed wallch_2.1.orig.tar.gz. You can't do that. Use quilt or make the package native
[20:03] <directhex> elmo, does your backlog tell you which version of the kernel package you updated from?
[20:04] <elmo> directhex: no, sorry - it was a 2.6.24-27, but I don't know which version
[20:05] <directhex> -i386?
[20:05] <directhex> wait, is that a type of kernel build in ubuntu? i lost track
[20:07] <elmo> Linux vernadsky 2.6.24-29-server #1 SMP Wed Aug 10 17:10:21 UTC 2011 i686 GNU/Linux
[20:07] <elmo> directhex: ^-- it use to be -27- - it's a component of the version number
[20:07] <hakermania> tumbleweed, Ok, I got it. Can't I upload a 2.2 version with different orig.tar.gz?
[20:08] <hakermania> tumbleweed, I will add a wallch PPA to the Wallch Team in lp now, it will be V2.1. Should I include the ~ppa1 or not?
[20:09] <directhex> elmo, okay, thanks. i'll try an original 8.04 iso in a VM, and update to -27-server
[20:10] <tumbleweed> hakermania: whatever you want, but I generally recommend using lower versions in PPAs than in ubuntu. It's up to you how you want to version it, think it through
[20:14] <maktrix> merged friends account with mine, how to split?
[20:17] <directhex> if memory serves, hardy shipped with -23 or -24
[20:19] <arune> hello, Im a launchpad newbie, currently I have launchpad to build binaries for a server software in a homeautomation project in a ppa
[20:20] <arune> Id like to know if there is some easy way to add libv8-2.5.9.9 to my ppa so that the users of my ppa can upgrade that since my homeautomation software depends on that version
[20:22] <arune> (or any way other than uploading the source package for libv8 and having launchpad build it for me)
[20:24] <hakermania> tumbleweed, version 2.1 will be sent to revu for review soon. It fixes the things you commented about and plus some bugs
[20:24] <hakermania> So the version will be the same
[20:25] <hakermania> Nice, it build fine :)
[20:26] <hakermania> I need some guidance here. I need to provide ppas both for gnome 2 and gnome 3, what should I do? Create different ones?
[20:27] <maxb> maktrix: Oh dear. Not possible. One of you will have to create a brand new account.
[20:29] <maxb> hakermania: Probably, yes. Your options are either separate PPAs, or ditinguishing the packages by different package names in a single PPA.
[20:31] <arune> anyone? Im googling like crazy :)
[20:33] <arune> https://help.launchpad.net/Packaging/PPA/Copying ?
[20:36] <hakermania> maxb, so I could name the one ~GNOME2ppa and the other ~GNOME3ppa? Also how can I overcome the orig.tar.gz error? By uploading newer version of the posted one?
[20:42] <maxb> hakermania: No. You'd have to change the package *name*, not the version
[20:43] <maxb> https://code.launchpad.net/~bzr/+archive/daily/+build/2735315 appears to be stuck. Could someone stab karkalla?
[20:43] <maxb> Or I guess the no-output timeout will stab it eventually
[20:44] <maxb> huh,
[20:44] <maxb> Apparently it's not stuck, just going insanely slowly
[20:46] <hakermania> maxb, for example I tried uploading the ~ppa2 after ~ppa1 (which are different names actually) and I got the orig.tar.gz error :/
[20:46] <maxb> So don't change the contents of the .orig.tar.gz
[20:50] <hakermania> maxb, how so? I made a little change of a file, and then I created again a tar.gz, run again dh_make which made the new orig.tar.gz...A little change requires new orig.tar.gz file
[20:52] <tumbleweed> hakermania: it doesn't require a new .orig.tar.gz, don't re-run dh_make
[20:53] <hakermania> tumbleweed, then where does the change is saved?
[20:53] <tumbleweed> hakermania: preferably as a quilt patch. Have you read the ubuntu packaging guide?
[20:57] <hakermania> tumbleweed, yes I had once upon a time.
[20:57] <tumbleweed> read the section on patch systems
[20:58] <hakermania> tumbleweed, doing so
[21:05] <maxb> hakermania: What are you packaging, anyway?
[21:06] <maxb> And why are you re-running dh_make? It's a one-time getting-started tool
[21:09] <hakermania> maxb, I am packaging my app, wallch. And I don't know why but I am constantly ruunning dh_make from the beggining. Ok, now I learned about the patch-system, but I still not get how the changes of the patch will be included to the new uploaded ppa
[21:09] <tumbleweed> hakermania: I thought your app was Qt. Why does it care abuot gnome2 vs gnome3?
[21:11] <hakermania> tumbleweed, Qt cannot change desktop background hehe, we call gconftool on gnome 2 and gsettings on gnome 3
[21:11] <hakermania> plus some small changes to make parts of the code work
[21:12] <tumbleweed> hakermania: that sounds like something you rather want to detect at runtime (and maybe use their C/C++ APIs)
[21:15] <hakermania> tumbleweed, I was advised to make an app for GNOME 2.X and on for GNOME 3.X :)
[21:15] <hakermania> and sounds rational
[21:18] <hakermania> can someone explain me how does the made patch is uploaded? Does lp unpacks the orig.tar.gz and applies it, then rebuilds?
[21:18] <hakermania> And when you have uploaded a ppa to lp, then you make only patches that apply to the initial one?
[21:21] <directhex> elmo, fun times - still can't reproduce the issue in a VM, with hardy/2.6.24-27-server :p
[21:28] <maxb> hakermania: So.. err, you're making changes to your upstream app? Not to the packaging thereof?
[21:29] <maxb> In that case, you generally would *not* use a patch system, but you *would* change the upstream version number.
[21:29] <maxb> However, I agree with tumbleweed, it seems needlessly overcomplex to ship two versions of the app just to call different command line tools
[21:31] <hakermania> maxb, there are some changes as well to the versions, not only a command-line tool. Explain me a bit, when should I use the patch system, how would i upload with it and when should I change the upstream version number (I do the latter when I do minor changes to the proram)
[21:33] <maxb> A patch system is relevant for storing a set of separate changes which need to be applied to the upstream source code, for the package
[21:34] <hakermania> maxb, and why not making these changes, re-packaging and changing the upstream version?
[21:35] <tumbleweed> hakermania: changing the upstream version every time you fix a typo means releasing a lot of upstream versions :) which is why you can use quilt to make minor changes on top of the last released version (or a native package to ignore all of this)
[21:37] <hakermania> tumblweweed, Ok, let's say that I have my source, uploaded to lp, using the ppa system. Then I realize that something is wrong and I make a patch. Do I simpy re-run the dput command for the same .changes file?
[21:37] <tumbleweed> no, .changes includes a hash
[21:37] <tumbleweed> you run debuild -S and it'll generate a new .changes
[21:38] <tumbleweed> (and if you are too lazy to drive quilt properly, it can generate an ugly quilt patch, too)
[21:38] <lifeless> hakermania: you need to update the version every time
[21:38] <tumbleweed> erm, dch for a new version, then debuild...
[21:39] <hakermania> lifeless, Oh, hold on. Uploading the new .changes file isn't enough?
[21:39] <hakermania> Also does this .changes file can be uploaded to revu as well, for a review?
[21:40] <lifeless> hakermania: uploading a new changes file for a new version is enough
[21:40] <lifeless> hakermania: but a common mistake new packagers make is thinking they can use the same version twice: you can't
[21:41] <hakermania> lifeless, so only a 2.1 version, if a change made you should go to 2.2, is this what you mean?
[21:41] <lifeless> hakermania: each version has to be totally unique - its a globally federated database, so once a version is out there, its no longer changable
[21:41] <lifeless> hakermania: yes or 2.1.1 or 2.1build1
[21:42] <maxb> Although a buildN suffix conventionally denotes a rebuild with no changes
[21:44] <hakermania> Question, if I make a patch, will lp rebuild it and make new DEBS?
[21:47] <hakermania> Also I uploaded the GNOME 2 package with the name of ~GNOME2ppa1 instead of ~ppa1 and it was rejected because of the orig.tar.gz file, again!
[21:47] <hakermania> I don't get it :(
[22:38] <hakermania> tumbleweed, for example how do I make a new version of the wallch_2.1-0ubuntu1~ppa1? Just make the patch, run debuild -S and reupload the .changes?
[22:57] <maxb> What on earth?
[22:58] <maxb> I just had a recipe build *source* build fail on lucid natty and oneiric
[22:58] <maxb> with a BzrCheckError
[22:58] <maxb> But exactly the same recipe for maverick succeeeded?!
[22:59] <maxb> Also, why are recipe source builds being conducted with: bzr 2.0.4 on python 2.5.2 (Linux-2.6.24-29-xen-x86_64-with-debian-lenny-sid)
[22:59] <maxb> ?!
[23:00] <hakermania> maxb, interesting facts :P
[23:08] <maxb> Looks like some builders are doing something very odd
[23:09] <maxb> Re-requesting new recipe builds has resulted in lucid succeeding
[23:09] <poolie> hi maxb
[23:10] <maxb> Hi poolie
[23:10] <maxb> Amusing conundrum I've found, isn't it :-)
[23:11] <poolie> hm
[23:11] <poolie> they consistently fail first and then succeed?
[23:12] <maxb> No, it seems to be random
[23:14] <poolie> that is strange
[23:14] <poolie> what does the failure look like, when it happens?
[23:16] <maxb> https://code.launchpad.net/~bzr/+archive/daily/+recipebuild/74703/+files/buildlog.txt.gz
[23:16] <maxb> There's a failing buildlog
[23:17] <maxb> Now, I know the dulwich branches have some dodgy text revisions in them, so the failure doesn't surprise me all that much
[23:17] <maxb> Apparently bzr has grown better able to handle missing records in the standard fetch at some point
[23:18] <maxb> But something deeply odd is happening, that there's still a copy of bzr 2.0.4 anywhere in the Launchpad infrastructure at this point
[23:20] <maxb> jelmer: Hi, do you happen to know where the copy of bzr that Launchpad uses during source package recipe builds is stored?
[23:20] <poolie> inside the builder image, i suppose, but i'm surprised by it too
[23:20] <maxb> It's not in the chroot tarball
[23:20] <poolie> i do know some of that stuff is build independently of launchpad itself
[23:21] <maxb> I'm also rather confused by bzr claiming it's running on debian-lenny-sid
[23:22] <wgrant> maxb: It was apparently decided to run bzr and bzr-builder outside the chroot.
[23:22] <wgrant> maxb: Which makes every rather disastrously confusing and awkward to debug and upgrade.
[23:22] <wgrant> maxb: (the initial implementation just used them as normal deps within the chroot)
[23:22] <wgrant> Let me find the relevant bzr package...
[23:23] <maxb> Well, at least that explains why the behaviour is varying - presumably it just depends on which builder ends up doing the build
[23:24] <wgrant> Yes, and we and LOSAs have no visibility into the builders :/
[23:25] <wgrant> Hmm.
[23:25] <wgrant> hardy-cat-buildd has 2.3.1-0.0.ISPATCHED.8.04.1, lucid-cat-buildd has 2.4.0~beta4-1ubuntu1~1.IS.10.04
[23:26] <wgrant> If there's anything other than those two around, something is pretty strange.
[23:26] <wgrant> But the buildds are *very* strange, so that would not be completely surprising.
[23:26] <maxb> Apparently these buildds are running lenny-vintage Debian testing!
[23:26] <wgrant> That seems less than entirely plausible, but let's see.
[23:27] <daker> hello
[23:27] <daker>  i have created https://launchpad.net/slumber & i have checked "I do not want to maintain this project" by mistake, so i can't control it anymore, any LP admin to help me pls :)
[23:27] <wgrant> daker: Let me reassign it back to you.
[23:28] <daker> woo thanks :)
[23:28] <wgrant> daker: It's yours again.
[23:28] <daker> yes thanks wgrant
[23:29] <wgrant> maxb: That log is rather worrying.
[23:29] <maxb> I thought so
[23:29] <wgrant> maxb: Have you seen any other similarly ancient builders?
[23:29] <wgrant> I would get IS to check, but all the APAC people are probably still flying or asleep.
[23:29] <wgrant> So that will have to wait until Europe, probably.
[23:29] <maxb> I've never seen this issue until now, but then, it's only shown up because the dulwich branches are a bit screwy
[23:30] <wgrant> The buildds might eventually be under LOSA maintenance, but until then everything around them is very awkward.
[23:30] <wgrant> This wasn't so important when just about everything ran inside the chroot.
[23:30] <maxb> Speaking of builders, karkalla is now nearly 4 hours in to a build which took between 5 and 8 minutes on other builders, for other series!
[23:31] <wgrant> But then they moved bzr and bzr-builder outside it, so the host environment is important :/
[23:31] <wgrant> I haven't done my morning sweep of the builders yet :) Killing.
[23:31] <wgrant> And killed.
[23:32] <maxb> I'm rather curious how it managed to take so long over a relatively tiny build
[23:32] <wgrant> karkalla is not known to be as flaky and hangy as, say, bohrium, but it's not known to be perfect either.
[23:33] <mwhudson> wgrant: is "chroot problems" being reported and looking like double frees inside bunzip2 a sign of a flaky builder?
[23:34] <wgrant> mwhudson: shipova?
[23:34] <wgrant> Or another builder?
[23:35] <mwhudson> wgrant: i don't actually remember, sorry
[23:35]  * mwhudson pokes at email
[23:35] <mwhudson> wgrant: shipova, yes
[23:35] <mwhudson> it was about a week ago, i guess
[23:36] <wgrant> mwhudson: It probably has dodgy RAM, and was disabled for that for a few days. It apparently got reenabled a while ago, but has been pretty severely hung over the weekend... I will set it to manual
[23:37] <mwhudson> wgrant: actually, friday at 05:10 my time it seems
[23:37] <mwhudson> i retried the build, so the log is gone of course
[23:37] <wgrant> (if you look at its history at https://launchpad.net/builders/shipova/+history, go back to the 19th and you'll see a... few failed builds)
[23:37] <mwhudson> wgrant: heh
[23:38] <mwhudson> glad it was a known issue anyway
[23:38] <elmo> the chroot problem thing is sudo
[23:39] <wgrant> elmo: Sure? That's the only builder I've seen it on, and sudo doesn't normally crash with a double free on a parse error, IME...
[23:39] <wgrant> Or was shipova the only one with the bad config?
[23:39] <wgrant> It's also hung again.
[23:39] <wgrant> So I'm suspicious of it anyway.
[23:39] <elmo> the double free on parse error is a red herring
[23:39] <elmo> it's the same sudo thing as back in march
[23:40] <elmo> lamont should have fixed it last week
[23:40] <wgrant> It has been working for three days, yes.
[23:40] <elmo> in any event, I hope you're going to file an RT or in some way let us know what's been done
[23:40] <wgrant> My faith in sudo is hugely increased...
[23:40] <wgrant> I was going to chat to lamont when he reappears.
[23:40] <wgrant> As everyone else seems to be scared of the buildds.
[23:40] <wgrant> And/or not know exactly what horrors have been perpetrated against them lately.
[23:41] <elmo> wgrant: please file an RT - you're only furthering the SPOF of lamont otherwise
[23:42] <wgrant> True, true.
[23:52] <daker> i have another question: why ppas can't be deleted for ever ? ex : https://launchpad.net/~daker/+archive/ppa
[23:52] <lifeless> they can be disabled forever
[23:53] <lifeless> but deleting entirely would remove all knowledge of their existence
[23:53] <lifeless> this would then allow you to create a new one with the same name
[23:53] <daker> even if it's empty ?
[23:53] <lifeless> and that would lead to breaking the version information constraints that prevent apt and dpkg on users machines being confused
[23:54] <daker> i see