[01:33] <lifeless> wow, i386 backlog :(
[01:34] <wgrant> lifeless: Network issues look to have killed most of the buildds.
[01:34] <wgrant> Somebody just needs to hit the checkbox...
[01:35] <wgrant> lifeless: Also note that most of those builds are scored at -10, as they're part of the archive rebuild.
[01:35] <wgrant> So normal PPA builds will be way in front of the other 7000.
[01:36] <lifeless> wgrant: I just uploaded a subunit update; its slated for 1 hour - which is why I made my comment
[01:36] <lifeless> are you talking about nannyberry etc?
[01:36] <wgrant> lifeless: Yeah.
[01:36] <wgrant> Ah, so you're not talking about the *really* big backlog.
[01:37] <lifeless> time to start  pinging arbitrary folk in that team :)
[01:39] <lifeless> https://edge.launchpad.net/builders/ says there isn't a i386 distro rebuild in progress :P
[01:39] <lifeless> unless its being done deliberately on ppa builders?
[01:40] <wgrant> lifeless: Rebuilds are done on the virtual builders.
[01:40] <lifeless> interesting
[01:40] <lifeless> I wish I could click into the queue to browse
[01:41] <wgrant> There are often 10 times more virtual buildds. If rebuilds happened on the non-virtual buildds, it would take just three long-running builds to block Ubuntu i386 builds for a day.
[01:42] <wgrant> lifeless: most of the queue is in https://launchpad.net/ubuntu/+archive/test-rebuild-20090909.
[01:42] <lifeless> nice hack, separate archive ;)
[01:42] <lifeless> does it get binary copied back afterwards?
[01:43] <wgrant> I wouldn't really call that a hack.
[01:43] <wgrant> The binaries can't be copied back; the versions would conflict.
[01:43] <lifeless> so its simply a test
[01:43] <wgrant> Now, the other uses of archives, those are hacks.
[01:43] <wgrant> Right.
[01:43] <lifeless> hacks are clever solutions
[01:44] <wgrant> I have a script which digests the build data from that archive into a rather more useful form: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909.html
[01:44] <lifeless> cool
[01:44] <lifeless> so by queue, I mean on /builders
[01:45] <wgrant> Right. I filed a bug for that about two years ago.
[01:45] <wgrant> I'm not quite sure how it would work.
[01:45] <lifeless> well there is a number coming from some list
[01:45] <lifeless> show the list?
[01:46] <wgrant> I guess there is now a nice table that can be linkified, so the UI is easier.
[01:46] <wgrant> Let's see how hard that is to implement...
[01:51] <lifeless> wgrant: is there a bug on auto recovery of virtual builders
[01:51] <lifeless> from no route etc errors?
[01:52] <wgrant> lifeless: There was a bug a while ago from elmo complaining that the builddmaster expected to live in the ivory tower of perfect networks...
[01:52] <wgrant> lifeless: It's at the moment quite deliberate that they're killed permanently. But there are feature requests asking for it to retry.
[01:53] <lifeless> huh
[01:53] <wgrant> This is a different issue from the common no route to host one, though
[01:54] <wgrant> In this case the builder was contactable, but sent back a BUILDERFAIL when it couldn't talk to the librarian.
[01:54] <lifeless> I wish https://edge.launchpad.net/~mono-testing/+archive/ppa/+build/1049994 showed the score when it started
[01:54] <wgrant> The builddmaster cannot know in the current protocol whether the failure is transient.
[01:56] <wgrant> lifeless: Why?
[01:56] <lifeless> wgrant: a proxy for queue depth
[01:56] <wgrant> lifeless: PPA build scores are very very boring.
[01:57] <lifeless> nevertheless
[01:58] <lifeless> I wonder if we should start getting arch indep binaries from the amd64 builders
[01:58] <wgrant> lifeless: Probably not. There is a better solution.
[01:58] <lifeless> don't tease me like that
[01:58] <wgrant> lifeless: Pool the i386/amd64/lpia virt/non-virt builders.
[01:59] <lifeless> wgrant: I'm not quite sure what you mean by that; unless you mean 'get the arch indep binaries from the first build that completes'
[02:00] <wgrant> lifeless: At the moment, the i386 queue is overloaded because there are fewer builders and more builds on i386.
[02:00] <lifeless> so right now, I'm spinning on the i386 builders to be able to test subunit 0.0.2 on amd64
[02:00] <wgrant> lifeless: Now, the i386/amd64/lpia are the same architecture.
[02:00] <wgrant> lifeless: So there's no reason they can't build all three archs.
[02:01] <wgrant> If they are stuck into a multi-arch pool with an intelligent queue algorithm, the i386 overloading goes away.
[02:01] <lifeless> I think you'd make your point more clearly if you said 'we should dynamically provision VM's [within the hardware capacity] to meet the build queue needs
[02:01] <wgrant> That's not quite it.
[02:02] <lifeless> so, AIUI the vm's are not the same arch; the hardware is and can run all the vm's
[02:02] <lifeless> and each vm uses a chroot to build a package
[02:03] <lifeless> last time I recall this part of the system being discussed there were serious concerns about changing what builds do if you do a cross arch build in a chroot [rather than in a vm]
[02:04] <lifeless> and yes such packages are arguably buggy
[02:05] <wgrant> Bug #285207
[02:05] <ubottu> Launchpad bug 285207 in soyuz "Pooling of buildds between distro and PPA" [Medium,Triaged] https://launchpad.net/bugs/285207
[02:05] <wgrant> Bug #285206
[02:05] <ubottu> Launchpad bug 285206 in soyuz "builddmaster needs to be able to deal with "random arch" buildds" [Medium,Triaged] https://launchpad.net/bugs/285206
[02:06] <wgrant> Lots of the lpia buildds were running amd64 VMs. I'm not sure about now, though.
[02:06] <lifeless> thanks
[02:10] <wgrant> The only difficult part of fixing those is the scoring algorithm./
[02:20] <wgrant> lifeless: I see somebody revived the builders ten minutes ago.
[02:41] <lifeless> wgrant: cool
[02:42] <lifeless> wgrant: whats current 'best way to do it' for buildings stuff on hardy + intrepid + jaunty + karmic?
[02:42] <wgrant> lifeless: Hope you can copy forward.
[02:43] <lifeless> source only copies?
[02:43] <wgrant> Not supported.
[02:43] <wgrant> You have to copy with binaries.
[02:43] <lifeless> k
[02:43] <lifeless> otherwise add the suite to the version?
[02:44] <wgrant> If a forward binary copy won't work for that package, you'll have to script multiple uploads like ~hardy1, ~intrepid1, etc.
[02:44] <wgrant> I'm not sure if AutoPPA still exists, but it used to automate it.
[02:44] <lifeless> yah
[02:44] <lifeless> it does
[02:44] <lifeless> I nagged jkakar today about that :)
[02:54] <jkakar> Nagging can be effective--though, don't tell my wife I said that. ;)  I just uploaded a test build of AutoPPA 0.0.6 to my PPA... once the build completes and I test it, I'll upload packages to the official PPA.
[03:18] <lifeless> \o/
[03:18] <lifeless> jkakar: have you considered getting it into Debian?
[03:19] <jkakar> lifeless: I've thought of it, but haven't actually done anything about it.
[03:25] <lifeless> jkakar: you really should :)
[03:25] <lifeless> if its in debian, its in ubuntu
[03:25] <lifeless> and the first place /everyone/ using Ubuntu looks for software is synaptic
[08:32] <alkisg> Is keyserver.ubuntu.com down?
=== doko__ is now known as doko
[10:56] <happyaron> danilos, You have reach your quota for direct contact of other Launchpad users. You can try again in 19 hours , what's this for?
[11:00] <lifeless> spammers
[11:56] <happyaron> lifeless, spammer?
[11:56] <wgrant> happyaron: If there was no limit, a spammer could create a Launchpad account and quickly use Launchpad as a sort of mail relay to spam a million peopl.
[11:57] <happyaron> wgrant, oh
[11:57] <happyaron> wgrant, I am contacting some of my team member who didn't provide public address, but soon I get that
[12:13] <quentusrex> wgrant: would you mind taking a look at a debian/rules line of code?
[12:13] <quentusrex> find $$SBDIR/$$I/48000 -name \*.wav -exec sox {} -r $$RATE $$SBDIR/$$I/$$RATE/`basename {}` \; ; \
[12:13] <quentusrex> the `basename {}` isn't working...
[12:14] <quentusrex> it isn't stripping the directories off the front of the files found by find.
[12:14] <wgrant> quentusrex: What's it doing insteaD?
[12:15] <quentusrex> where the `basename {}` should be returning just "stuff.wav"
[12:15] <ojwb> well, the `` will be run "up front"
[12:15] <ojwb> not when the -exec is run
[12:15] <quentusrex> it's returning: "this/dir/and/that/dir/stuff.wav"
[12:15] <ojwb> sso it's `basename {}` -> {}
[12:15] <quentusrex> aah
[12:15] <quentusrex> is there a way to 'fix' it?
[12:16] <ojwb> I'd probably do: for f in `find .... -name \*.wav` ; do sox $f ....`basename $f` ; done
[12:33] <quentusrex> is there a way to tell the script to wait for background tasks to finish?
=== warp10_ is now known as warp10
=== sayakb_ is now known as sayakb
[14:45] <pmjdebruijn> lo
[14:46] <pmjdebruijn> is it possible to access historical versions of a PPA?
[14:46] <pmjdebruijn> to downgrade?
[15:02] <AskHL_> Hi, I would like to make a debian package, something that might go into a Personal Package Archive or something.  I can manage to create a package by hand by following a guide, but it's sort of tricky procedure with many steps, at least one of which I'll probably forget at some point (like getting the version numbers right everywhere).  How do normal people cope with this?  I'm thinking along the lines of making a big old shellscript
[15:03] <AskHL_> As it happens, I'm following the Ubuntu Python packaging guide, https://wiki.ubuntu.com/PackagingGuide/Python
[15:20] <pmjdebruijn> AskHL_: packaging can't easily be automated
[15:20] <pmjdebruijn> AskHL_: if that were easy, we wouldn't really need a lot of package maintainers
=== sayakb_ is now known as sayakb
=== mpt_ is now known as mpt
=== happyaron_ is now known as happyaron
=== pwolanin is now known as pwolanin|afk
[16:48] <wattazoum> hi
=== sayakb_ is now known as sayakb
[17:39] <MFen> is there an api to check whether a ppa source has finished building?
[17:39] <MFen> or better yet block until it does?
[17:40] <quentusrex> MFen: why?
[17:41] <MFen> quentusrex: i'm trying to automate my release process (https://bugs.launchpad.net/hypy/+bug/333532)
[17:41] <ubottu> Launchpad bug 333532 in hypy "Automate steps 4-5 of the release process" [Medium,Confirmed]
[17:41] <MFen> step 4 is "wait for confirmation that the build finished" and step 5 is "copy packages to another dist"
[17:42] <MFen> i know there's an api for 5
[17:42] <MFen> pretty sure that's syncSource
[17:47] <MFen> basically my build process is a makefile that prompts before it does irreversible things. so I *could* just have the prompt say "visit http://xx to watch the build process, then press enter when the package has finished building", then call syncSource
[17:47] <MFen> but that seems silly since i'd already be there at the website
[17:47] <MFen> i'd rather have it just check once a minute or so until the builds are done, then announce success
[17:49] <maxb> MFen: So, use the API to poll the contents of the PPA, I guess
[17:49] <MFen> yeah. but i don't know which api to use :)
[17:49] <MFen> i've never done anything with this api before
[17:50] <maxb> that's what the apidoc's for :-)
[17:50] <MFen> is there better doc that https://staging.launchpad.net/+apidoc/ ?
[17:50] <MFen> it's not clear what i'm supposed to do from reading that
[17:50] <MFen> i see a few different apis that could be it, and not much information about how to construct the requests
[17:51] <james_w> MFen: poll getPublishedBinaries I think
[17:51] <maxb> Don't worry about constructing the requests, just use launchpadlib
[17:51] <MFen> yeah, not much info about that either
[17:51] <MFen> getPublishedBinaries sounds like a good one, ok
[17:52] <MFen> nm i googled it, i think i can take it from here. thanks :)
[17:52] <james_w> that's not checking the builds though
[17:52] <james_w> so it won't be able to detect failed builds
[17:52] <MFen> well, i *would* like to know if a build fails
[17:52] <MFen> so i can bail out early. otherwise i'll have to time out
[17:54] <james_w> getBuildRecords
[17:54] <james_w> getBuildSummariesForSourceIds
[17:54] <james_w> they might be of use
[17:56] <MFen> thanks
[20:07] <jkakar> A new AutoPPA release is available at https://launchpad.net/autoppa!
[20:07] <jkakar> lifeless: ^^ :)
[20:21] <virtuald> launchpad thanks me twice for my commend and it doesn't show up immediately but it's there when i reload the page after a few seconds
[20:22] <virtuald> comment*
[20:28] <virtuald> hmm now it doesn show up just because i said that
[20:28] <virtuald> shift-reload and it's there..
[20:30] <virtuald> bah. probably firefox extensions trouble.
[20:34] <alasdair> is keyserver.ubuntu.com service down? I can ping the url but I can't seem to send my key
=== rmcbride_ is now known as rmcbride
[21:50] <CarlFK> is there a way to upload source to my PPA and have it built against more than one release?
[21:51] <CarlFK> like jaunty, intrepid, karmic
[21:51] <beuno> CarlFK, not at the moment
[21:52] <CarlFK> thanks.  I'll stop trying to figure out how :)
[22:25] <geser> CarlFK: you need to do a upload for each Ubuntu release you want your package build (with different versions, e.g. by appending jaunty, intrepid or karmic to the version)
[22:37] <avar> Where can I find where the commit referenced as "RF 4887" here was made: https://bugs.launchpad.net/rosetta/+bug/3990
[22:37] <ubottu> Launchpad bug 3990 in rosetta "Need to support KDE like translation context" [High,Fix released]
[22:37] <avar> I'd like to view a diff of it to see how this feature works
[22:38] <avar> I'm working on a project which would like to use context in translations. But can't use the normal gettext facility for that because the Java gettext library sucks. So using the standard KDE hack looks like the way to go since launchpad supports it.
[22:49] <Fly-Man-> Question:
[22:49] <Fly-Man-> How do I checkout a Bazaar trunk into Launchpad ?
[22:53] <wgrant> Fly-Man-: How does it make sense to check something out *into* Launchpad, and why would you want to?
[22:53] <Fly-Man-> wgrant, as I have a bzr trunk now
[22:54] <Fly-Man-> but I receive this error
[22:54] <Fly-Man-> bzr: ERROR: Transport error: Server refuses to fullfil the request
[22:54] <wgrant> Fly-Man-: What are you trying to do?
[22:54] <Fly-Man-> I'm trying to grab a bzr trunk
[22:55] <wgrant> What command are you executing?
[22:55] <Fly-Man-> and I thought to proper way to get one is
[22:55] <Fly-Man-> bzr branch <url> branchname
[22:56] <wgrant> That's right. What is the exact command that you are executing?
[22:57] <Fly-Man-> wgrant IM