User1: bleh, just got a timeout trying to create a project
User1: wait, no
User1: the timeout was just loading the project page after it was created, nevermind
User2: That's still very odd. Do you have an OOPS ID?
User1: OOPS-2059DW4
User3: https://lp-oops.canonical.com/oops.py/?oopsid=2059DW4
User4: Thanks.
User1: URL was https://launchpad.net/mantissa
User1: (although I guess that's probably in the OOPS info anyway?)
User4: I think I might know what it is, but we'll see shortly...
User4: Yup.
User4: Yeah, 8.5s query trying to guess at possibly relevant source packages...
User4: There's a bug for that.
User4: Bug #739051
User3: Launchpad bug 739051 in Launchpad itself "Product:+index timeouts" [Critical,Triaged] https://launchpad.net/bugs/739051
User5: wow, that's a very complicated bug to rread.
User5: *read
User4: Heh.
User4: lifeless has that effect on people.
User4: er, bugs.
User5: Haha
User1: haha
User5: which bit is timing out? the source distribution bits?
User4: Yeah. It's the fti/ILIKE stuff.
User5: Lets make everything XHR! :)
User6: User4 User5 it is however suitable for an engineer to work on :)
User5: User6 Hah, ok I may have to agree there :)
User7: 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.
User8: is it possible to use https://launchpad.net/ubuntu/+ppas to search for packages in a certain series?
User9: User8 I don't think it's possible at the moment
User8: User9 OK, but it would be a useful addition
User9: User8 I agree; you're always welcome to file a wishlist bug against the Launchpad project for things like this
User8: https://bugs.launchpad.net/launchpad/+bug/830519
User3: Ubuntu bug 830519 in Launchpad itself "Would like to be able to search PPAs for build series" [Undecided,New]
User10: 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/
User10: err
User10: This changelog: http://paste.ubuntu.com/671780/
 * 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)
User10: tumbleweed, what is a ~ppa1? And whenever I want can't I delete a ppa and upload another one?
User11: User10 something to append to the version: 2.1-0ubuntu1~ppa1 No you can't re-upload the same version again, ever
User10: tumbleweed, Can't I do tests? To see how it works?
User10: Ok i see
User12: did we confirm that rothera and vernadsky are running a Lucid 2.6.32 kernel?
User12: we've isolated the mono build problem to an issue with EPOLL that only happens on those boxes
User13: User12 they're running hardy, not lucid
User5: User12 Testing mono builds on lucid host was the first time I got a "sad" reply to "build success!" :)
User10: 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.
User12: elmo, ah. which kernel is that?
User11: User10 yes, you change the changelog, Read the errors, they may be helpful
User12: 2.6.24. hm
User12: nigelb, yeah :/
User12: elmo, and the same applies for roseapple, which built okay?
User13: User12 all the buildds are still hardy, AFAIK
User13: User12 roseapple is on a slightly newer kernel
User12: 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
User13: User12 how about I just upgrade vernadsky + rothera to current?
User13: and I'll file an RT about getting them all up-to-date (they should have been anyway - obviously)
User12: 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
User13: User12 if the bug is only present in obsolete versions of the hardy kernel, I don't see that as sweeping stuff under the rug
User12: elmo, try it, i guess. ping me when it's updated, and i'll request a sync of 2.10.4-3
User14: its probably been fixed in later kernels, is my guess
User13: (by the way, by current I mean current hardy - not lucid or something)
User14: mhm
User13: 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
User12: looks like the builders are mostly idle, so nobody should notice a reboot
User13: User12 done
User12: that was quick
User15: fancy taking one offline to test-rebuild mono in its chroot? :P
User12: that'd be phenomenally useful, but i don;t know if it's possible :/
User15: maybe elmo is feeling benevolent
User13: User15 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
User15: fair enough
User15: thanks for your help this far
User15: it'll be easier to try a sync of -3 at that point (but you can bet it gets picked by roseapple)
User13: well
User13: that's easy to fix
User13: I'll put roseapple into manual
User13: done - all but rothera/vernadsky are in manual
User13: if you can sync it now, go ahead - we'll wait it for to start building  then I'll unmanual the others
User15: erm, it's not actually uploaded to debian yet
User13: well, then I'll not do that..
User15: sorry
User16: 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 :)
User9: User16 there are links on launchpad.net to them
User9: User16 there is no public index or anything like that for the librarian, it's just a file store used by launchpad
User16: User9 ahhh...ok thnak
User16: User9  ok thanks.... :)  will have to do some wading through the site itself then.   much appreciated
User9: what are you looking for specifically?
User16: User9  older linux kernels
User9: User16 just the tarballs, or packages?
User16: User9 probably packages would be best
User9: for the tarballs, kernel.org is probably a better place to look. For Ubuntu, see e.g. http://packages.ubuntu.com/linux
User16: User9  ahhh...ok.   when googling, one of the references for them was launchpad but will check out the two you have sent too.   thanks again. :)
User10: 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
User10: Will it disappear if I upload the 2.2 version or a ~ppa2?
User11: User10 it's saying you changed wallch_2.1.orig.tar.gz. You can't do that. Use quilt or make the package native
User12: elmo, does your backlog tell you which version of the kernel package you updated from?
User13: User12 no, sorry - it was a 2.6.24-27, but I don't know which version
User12: -i386?
User12: wait, is that a type of kernel build in ubuntu? i lost track
User13: Linux vernadsky 2.6.24-29-server #1 SMP Wed Aug 10 17:10:21 UTC 2011 i686 GNU/Linux
User13: User12 ^-- it use to be -27- - it's a component of the version number
User10: tumbleweed, Ok, I got it. Can't I upload a 2.2 version with different orig.tar.gz?
User10: 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?
User12: elmo, okay, thanks. i'll try an original 8.04 iso in a VM, and update to -27-server
User11: User10 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
User17: merged friends account with mine, how to split?
User12: if memory serves, hardy shipped with -23 or -24
User18: hello, Im a launchpad newbie, currently I have launchpad to build binaries for a server software in a homeautomation project in a ppa
User18: Id like to know if there is some easy way to add libv8-91.69.162.6 to my ppa so that the users of my ppa can upgrade that since my homeautomation software depends on that version
User18: (or any way other than uploading the source package for libv8 and having launchpad build it for me)
User10: tumbleweed, version 2.1 will be sent to revu for review soon. It fixes the things you commented about and plus some bugs
User10: So the version will be the same
User10: Nice, it build fine :)
User10: I need some guidance here. I need to provide ppas both for gnome 2 and gnome 3, what should I do? Create different ones?
User19: User17 Oh dear. Not possible. One of you will have to create a brand new account.
User19: User10 Probably, yes. Your options are either separate PPAs, or ditinguishing the packages by different package names in a single PPA.
User18: anyone? Im googling like crazy :)
User18: https://help.launchpad.net/Packaging/PPA/Copying ?
User10: 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?
User19: User10 No. You'd have to change the package *name*, not the version
User19: https://code.launchpad.net/~bzr/+archive/daily/+build/2735315 appears to be stuck. Could someone stab karkalla?
User19: Or I guess the no-output timeout will stab it eventually
User19: huh,
User19: Apparently it's not stuck, just going insanely slowly
User10: maxb, for example I tried uploading the ~ppa2 after ~ppa1 (which are different names actually) and I got the orig.tar.gz error :/
User19: So don't change the contents of the .orig.tar.gz
User10: 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
User11: User10 it doesn't require a new .orig.tar.gz, don't re-run dh_make
User10: tumbleweed, then where does the change is saved?
User11: User10 preferably as a quilt patch. Have you read the ubuntu packaging guide?
User10: tumbleweed, yes I had once upon a time.
User11: read the section on patch systems
User10: tumbleweed, doing so
User19: User10 What are you packaging, anyway?
User19: And why are you re-running dh_make? It's a one-time getting-started tool
User10: 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
User11: User10 I thought your app was Qt. Why does it care abuot gnome2 vs gnome3?
User10: tumbleweed, Qt cannot change desktop background hehe, we call gconftool on gnome 2 and gsettings on gnome 3
User10: plus some small changes to make parts of the code work
User11: User10 that sounds like something you rather want to detect at runtime (and maybe use their C/C++ APIs)
User10: tumbleweed, I was advised to make an app for GNOME 2.X and on for GNOME 3.X :)
User10: and sounds rational
User10: can someone explain me how does the made patch is uploaded? Does lp unpacks the orig.tar.gz and applies it, then rebuilds?
User10: And when you have uploaded a ppa to lp, then you make only patches that apply to the initial one?
User12: elmo, fun times - still can't reproduce the issue in a VM, with hardy/2.6.24-27-server :p
User19: User10 So.. err, you're making changes to your upstream app? Not to the packaging thereof?
User19: In that case, you generally would *not* use a patch system, but you *would* change the upstream version number.
User19: However, I agree with tumbleweed, it seems needlessly overcomplex to ship two versions of the app just to call different command line tools
User10: 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)
User19: 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
User10: maxb, and why not making these changes, re-packaging and changing the upstream version?
User11: User10 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)
User10: 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?
User11: no, .changes includes a hash
User11: you run debuild -S and it'll generate a new .changes
User11: (and if you are too lazy to drive quilt properly, it can generate an ugly quilt patch, too)
User6: User10 you need to update the version every time
User11: erm, dch for a new version, then debuild...
User10: lifeless, Oh, hold on. Uploading the new .changes file isn't enough?
User10: Also does this .changes file can be uploaded to revu as well, for a review?
User6: User10 uploading a new changes file for a new version is enough
User6: User10 but a common mistake new packagers make is thinking they can use the same version twice: you can't
User10: lifeless, so only a 2.1 version, if a change made you should go to 2.2, is this what you mean?
User6: User10 each version has to be totally unique - its a globally federated database, so once a version is out there, its no longer changable
User6: User10 yes or 2.1.1 or 2.1build1
User19: Although a buildN suffix conventionally denotes a rebuild with no changes
User10: Question, if I make a patch, will lp rebuild it and make new DEBS?
User10: 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!
User10: I don't get it :(
User10: 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?
User19: What on earth?
User19: I just had a recipe build *source* build fail on lucid natty and oneiric
User19: with a BzrCheckError
User19: But exactly the same recipe for maverick succeeeded?!
User19: 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)
User19: ?!
User10: maxb, interesting facts :P
User19: Looks like some builders are doing something very odd
User19: Re-requesting new recipe builds has resulted in lucid succeeding
User20: hi maxb
User19: Hi poolie
User19: Amusing conundrum I've found, isn't it :-)
User20: hm
User20: they consistently fail first and then succeed?
User19: No, it seems to be random
User20: that is strange
User20: what does the failure look like, when it happens?
User19: https://code.launchpad.net/~bzr/+archive/daily/+recipebuild/74703/+files/buildlog.txt.gz
User19: There's a failing buildlog
User19: Now, I know the dulwich branches have some dodgy text revisions in them, so the failure doesn't surprise me all that much
User19: Apparently bzr has grown better able to handle missing records in the standard fetch at some point
User19: 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
User19: User9 Hi, do you happen to know where the copy of bzr that Launchpad uses during source package recipe builds is stored?
User20: inside the builder image, i suppose, but i'm surprised by it too
User19: It's not in the chroot tarball
User20: i do know some of that stuff is build independently of launchpad itself
User19: I'm also rather confused by bzr claiming it's running on debian-lenny-sid
User4: User19 It was apparently decided to run bzr and bzr-builder outside the chroot.
User4: User19 Which makes every rather disastrously confusing and awkward to debug and upgrade.
User4: User19 (the initial implementation just used them as normal deps within the chroot)
User4: Let me find the relevant bzr package...
User19: Well, at least that explains why the behaviour is varying - presumably it just depends on which builder ends up doing the build
User4: Yes, and we and LOSAs have no visibility into the builders :/
User4: Hmm.
User4: 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
User4: If there's anything other than those two around, something is pretty strange.
User4: But the buildds are *very* strange, so that would not be completely surprising.
User19: Apparently these buildds are running lenny-vintage Debian testing!
User4: That seems less than entirely plausible, but let's see.
User21: hello
User21: 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 :)
User4: User21 Let me reassign it back to you.
User21: woo thanks :)
User4: User21 It's yours again.
User21: yes thanks wgrant
User4: User19 That log is rather worrying.
User19: I thought so
User4: User19 Have you seen any other similarly ancient builders?
User4: I would get IS to check, but all the APAC people are probably still flying or asleep.
User4: So that will have to wait until Europe, probably.
User19: I've never seen this issue until now, but then, it's only shown up because the dulwich branches are a bit screwy
User4: The buildds might eventually be under LOSA maintenance, but until then everything around them is very awkward.
User4: This wasn't so important when just about everything ran inside the chroot.
User19: 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!
User4: But then they moved bzr and bzr-builder outside it, so the host environment is important :/
User4: I haven't done my morning sweep of the builders yet :) Killing.
User4: And killed.
User19: I'm rather curious how it managed to take so long over a relatively tiny build
User4: karkalla is not known to be as flaky and hangy as, say, bohrium, but it's not known to be perfect either.
User22: User4 is "chroot problems" being reported and looking like double frees inside bunzip2 a sign of a flaky builder?
User4: User22 shipova?
User4: Or another builder?
User22: User4 i don't actually remember, sorry
 * mwhudson pokes at email
User22: User4 shipova, yes
User22: it was about a week ago, i guess
User4: User22 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
User22: User4 actually, friday at 05:10 my time it seems
User22: i retried the build, so the log is gone of course
User4: (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)
User22: User4 heh
User22: glad it was a known issue anyway
User13: the chroot problem thing is sudo
User4: User13 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...
User4: Or was shipova the only one with the bad config?
User4: It's also hung again.
User4: So I'm suspicious of it anyway.
User13: the double free on parse error is a red herring
User13: it's the same sudo thing as back in march
User13: lamont should have fixed it last week
User4: It has been working for three days, yes.
User13: in any event, I hope you're going to file an RT or in some way let us know what's been done
User4: My faith in sudo is hugely increased...
User4: I was going to chat to lamont when he reappears.
User4: As everyone else seems to be scared of the buildds.
User4: And/or not know exactly what horrors have been perpetrated against them lately.
User13: User4 please file an RT - you're only furthering the SPOF of lamont otherwise
User4: True, true.
User21: i have another question: why ppas can't be deleted for ever ? ex : https://launchpad.net/~daker/+archive/ppa
User6: they can be disabled forever
User6: but deleting entirely would remove all knowledge of their existence
User6: this would then allow you to create a new one with the same name
User21: even if it's empty ?
User6: and that would lead to breaking the version information constraints that prevent apt and dpkg on users machines being confused
User21: i see
launchpad
Ubuntu IRC