| === mnepton is now known as mneptok | ||
| === EvilResistance is now known as Resistance | ||
| === zyga__ is now known as zyga-afk | ||
| Resistance | whats with my ppa build of a mysql backport continually being pushed back? initial estimates were 3 hours, then 6 hours, and its now 6.25 hours since upload, and it still has a two hours until build time. | 05:29 |
|---|---|---|
| wgrant | Resistance: The build queues are somewhat backlogged due to a major hardware failure yesterday. | 05:30 |
| Resistance | wgrant: that i'm aware of | 05:31 |
| Resistance | exactly *how* backlogged are we talking? | 05:31 |
| Resistance | because that was > 24 hours ago :/ | 05:31 |
| wgrant | Hmm, that's interesting. | 05:31 |
| wgrant | Which build? | 05:31 |
| Resistance | well the builds i submitted are just over 6 hours ago. i highly doubt theres so much backlog that a > 24 hour period of time wouldnt have cleared that backlog. https://launchpad.net/~trekcaptainusa-tw/+archive/backports/+build/2993138 <-- i386, and https://launchpad.net/~trekcaptainusa-tw/+archive/backports/+build/2993137 <-- amd64 | 05:32 |
| wgrant | Heh, there is :) | 05:33 |
| Resistance | ... | 05:33 |
| Resistance | then the question becomes whats the ETA on the clearing of said backlog? | 05:33 |
| wgrant | We have a few builders off doing various other things until the weekend, so we have only barely enough capacity left. And with the ~12 hour backlog left by yesterday's failure... | 05:34 |
| wgrant | Let me bump those builds up the queue a bit. | 05:34 |
| wgrant | "Start in 1 minute" | 05:34 |
| mardy | poolie: hi :-) | 06:34 |
| mardy | poolie: if all development happens upstream (in git), does it still make sense to mirror the repository in bzr? | 06:35 |
| poolie | well, it can make sense if you're getting some benefit out of it | 06:36 |
| poolie | can you commit to the upstream branch? | 06:36 |
| poolie | if the patch is really targetted to upstream and you can commit there, you might as well merge it to there directly | 06:36 |
| poolie | using either bzr-git or git | 06:36 |
| mardy | poolie: yes, I can commit upstream | 06:37 |
| mardy | poolie: but there's always the possibility that upstream requests some modifications to the patch | 06:38 |
| mardy | poolie: so I'm afraid that branches might diverge | 06:39 |
| poolie | right | 06:39 |
| poolie | so if there is really conceptually just one branch, it's better not to have two physical branches representing it | 06:39 |
| poolie | because they can diverge | 06:39 |
| mardy | poolie: in the upstream repository, I have a "ubuntu" branch which I control, and being in the same repository, I can take care of diversions more easily | 06:41 |
| mardy | poolie: so, what I was doing till now, was just pulling from thisgit "ubuntu" branch into LP's bzr branch | 06:41 |
| mardy | poolie: if people prefer to have the code in LP as well, is it possible to mark it as read-only? | 06:42 |
| mardy | poolie: like, inhibit merge requests, or at least warn that they'll have to go upstream? | 06:43 |
| poolie | yeah | 06:43 |
| poolie | i think the easiest thing is to just take them upstream | 06:43 |
| poolie | for instance get the 'download diff' url and pipe that into git apply-patch or similar | 06:43 |
| poolie | then mark it merged | 06:43 |
| poolie | it could be a bit smoother | 06:44 |
| mardy | poolie: that's smooth enough | 06:44 |
| poolie | there are a cluster of things we could improve around people who have made a proposal that's not quite in the right place | 06:44 |
| poolie | eg based off or targeting the wrong branch | 06:44 |
| mardy | poolie: is there a specific way to mark the repository as read-only, or is it just a matter of writing it in the project description? | 06:45 |
| lifeless | mardy: what do you mean by readonly? | 06:45 |
| mardy | lifeless: some form of indication to the LP user, which tells that merge requests should better be handle upstream | 06:46 |
| mardy | *handled | 06:47 |
| lifeless | so not readonly (as any non-owned branch is readonly), rather 'not primary' | 06:47 |
| mardy | lifeless: yes, exactly | 06:47 |
| lifeless | I think a reasonable bug would be to note that there isn't a way to do this today | 06:47 |
| wgrant | If the dev focus branch is an import then it will already point upstream, at least a bit. | 06:48 |
| wgrant | Is the dev focus branch not an import? | 06:48 |
| mardy | wgrant: no, unfortunately (https://launchpad.net/bugs/878085) | 06:49 |
| ubot5 | Ubuntu bug 878085 in Launchpad itself "NoSuchRevision error during git import" [High,Triaged] | 06:49 |
| wgrant | Hah | 06:49 |
| poolie | mardy, it would be useful if you say that on that bug, in case it helps jelmer | 06:51 |
| poolie | he'll be online in a couple of hours | 06:51 |
| mardy | poolie: good point, will do | 06:52 |
| === jibel_ is now known as jibel | ||
| mrevell | Morning | 08:56 |
| === dupondje_ is now known as dupondje | ||
| === bigjools changed the topic of #launchpad to: Build delays due to earlier hardware failure | https://launchpad.net/ | Help contact: bigjools | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ | User Guide: https://help.launchpad.net/ | Support: https://answers.launchpad.net/launchpad | ||
| === jrgifford is now known as Guest46496 | ||
| keffie_jayx_ | hello all | 13:18 |
| keffie_jayx_ | I am working on a daily-build ppa | 13:18 |
| keffie_jayx_ | I was wondering what happens to debian/changelog when the merging of to branches happens. My guess it is not used at all | 13:18 |
| === yofel_ is now known as yofel | ||
| dobey | keffie_jayx_: if two branches have the same files with different revision info, there is a conflict or divergence issue when you try to merge them | 13:44 |
| Resistance | so question regarding PPAs and builds that have missing dependencies... | 14:34 |
| bigjools | fire away | 14:34 |
| Resistance | i fulfilled the dependency by uploading a package that is sufficient into the same PPA, and the dep-wait'd builds were automatically resubmitted. | 14:35 |
| Resistance | is that normal? | 14:35 |
| bigjools | yes, depwait builds are checked periodically | 14:35 |
| Resistance | ah. next question. | 14:36 |
| Resistance | two days ago i'm aware hardware exploded on the librarian | 14:36 |
| Resistance | exactly how much of a backlog did that generate? | 14:36 |
| bigjools | see https://launchpad.net/builders | 14:36 |
| Resistance | because it took 12 hours for the dependency on a dep-wait'd build to be built and published | 14:36 |
| Resistance | (initial build time: 2 hours. next: 6 hours. next: 8 hours) | 14:37 |
| bigjools | yes, that's about the backlog at the moment | 14:37 |
| Resistance | (over a course of about 3 hours that's the time changes) | 14:37 |
| Resistance | well technically unless the uploads system is suspended, its theoretically to get past the backlog, no? | 14:38 |
| bigjools | it'll clear it in a day or so | 14:38 |
| Resistance | i highly doubt that bigjools, considering that yesterday the queue was just over 300, and now its over 800 (i386) | 14:44 |
| bigjools | Resistance: well if you don't believe me then that's your perogative | 14:44 |
| james_w | is branch scanning on the blink? | 14:48 |
| bigjools | james_w: not that I know of, how long has it been? | 14:49 |
| james_w | just a couple of minutes: https://code.launchpad.net/~jml/pkgme-binary/remove-ldd/+merge/84942 | 14:49 |
| james_w | four in fact | 14:49 |
| james_w | the propsal should be marked as merged now I beleive | 14:50 |
| james_w | there we go | 14:50 |
| james_w | just needed some patience obviously :-) | 14:51 |
| === Ursinha is now known as Ursinha-lunch | ||
| === deryck is now known as deryck[afk] | ||
| psusi | Curtis Gedak is the upstream maintainer of gparted, but lp shows the maintainer is registry administrators, and Curtis doesn't have permission to futz with bugs targeted to parted. This is the right place to get that fixed right? | 15:22 |
| bigjools | psusi: yes | 15:22 |
| psusi | and also associate the upstream bug tracker with the project | 15:22 |
| bigjools | psusi: I've made him maintainer | 15:23 |
| bigjools | he can set the bug tracker now | 15:24 |
| psusi | ahh, cool | 15:26 |
| psusi | now, what exactly do you set the upstream bug pointer to? is http://gparted.org/bugs.php fine, or does it need a more specific url to do the automatic linking? | 15:27 |
| bigjools | psusi: it offers you a selection of know bugtrackers | 15:37 |
| bigjools | known* | 15:37 |
| bigjools | so you tell it which type it is and put the URL in | 15:37 |
| === deryck[afk] is now known as deryck | ||
| buzz_ | 11 hour queue on launchpad builders again. it seems every time i upload to the ppa there is a massive delay. hard to support the ubuntu users like this. also no longer allowed to look at the https://launchpad.net/builders page ? | 16:34 |
| bigjools | buzz_: some builders have been removed until saturday, the queue will be long until Sunday | 16:34 |
| buzz_ | :( | 16:35 |
| bigjools | there is also a bug preventing users seeing /builders if it has a private recipe build on it | 16:35 |
| Laney | hah, I was /just/ going to ask why that was | 16:37 |
| === Quintasan_ is now known as Quintasan | ||
| === Ursinha-lunch is now known as Ursinha | ||
| colon_D | Hi I want my PPA package to build for lucid natty and oneiric, right now I have trafficserver (3.0.2-1ubuntu5) oneiric; urgency=low -- if I change oneiric to unstable like I have seen others use what releases does that build against? | 19:56 |
| bigjools | you need to modify the package version and re-upload for each release | 19:57 |
| === bigjools changed the topic of #launchpad to: Build delays due to earlier hardware failure | https://launchpad.net/ | Help contact: - | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ | User Guide: https://help.launchpad.net/ | Support: https://answers.launchpad.net/launchpad | ||
| colon_D | Ahh, OK. Can I just dch -e and dput the resulting .source without conflict? | 19:58 |
| bigjools | as long as you don;t upload the same file versions again | 19:58 |
| bigjools | most people put the series name in the version | 19:58 |
| colon_D | that would be wise -- thanks bigjools :-) | 19:59 |
| dchilton | hi. when I wget a file to my linux box, no problems -- unless it's from launchpad. then, I get a message: "Resolving launchpadlibrarian.net (launchpadlibrarian.net)... failed: Name or service not known.; wget: unable to resolve host address `launchpadlibrarian.net'" | 20:11 |
| dchilton | here's the detail from @shell -> http://pastebin.com/gQMGVeLd . not at all sure what to do here ... :-/ | 20:11 |
| lifeless | what does | 20:11 |
| lifeless | host launchpadlibrarian.net | 20:12 |
| lifeless | output for you? | 20:12 |
| lifeless | and whats in your resolv.conf | 20:12 |
| dchilton | lifeless: host launchpadlibrarian.net --> launchpadlibrarian.net has address 91.189.89.228; launchpadlibrarian.net has address 91.189.89.229 | 20:12 |
| lifeless | looks correct | 20:12 |
| ams_cs | I'm having trouble uploading a release file to LP | 20:13 |
| lifeless | so, resolving works | 20:13 |
| lifeless | dchilton: wget should get the same result | 20:13 |
| dchilton | lifeless: resolv.conf contins -> "nameserver 208.201.224.11; nameserver 208.201.224.33" | 20:13 |
| dchilton | lifeless: i'd think so too, but, well, it appears not to ... | 20:14 |
| lifeless | ams_cs: some details might help us sort that out :P | 20:14 |
| ams_cs | :) | 20:14 |
| lifeless | dchilton: try wget http://208.201.224.33/83787268/libmemcached-1.0.2.tar.gz | 20:14 |
| dchilton | lifeless: er, from my DNS server? | 20:15 |
| lifeless | no from the machine that is doing wget | 20:15 |
| ams_cs | I'm trying to upload a 70MB file to https://launchpad.net/gcc-linaro/4.6/4.6-2011.12/ | 20:15 |
| dchilton | lifeless: 208.201.224.33 is a dns server ... why try to get a file FROM it? | 20:16 |
| lifeless | oh bah | 20:16 |
| lifeless | I meant to put 91.189.89.228 in as the ip | 20:16 |
| lifeless | / host | 20:16 |
| dchilton | heh ... sec | 20:16 |
| ams_cs | it's failed 5 times already - gets to 100% and then gives the normal launchpad error "please contact #launchpad" if it persists | 20:16 |
| dchilton | lifeless: same thing -> Resolving launchpadlibrarian.net (launchpadlibrarian.net)... failed: Name or service not known. | 20:17 |
| lifeless | ams_cs: does it give an OOPS id ? | 20:18 |
| ams_cs | the other file I had to upload today went through on the second attempt, but this one not | 20:18 |
| lifeless | dchilton: huh? you put an ip address in and it still ends up on the hostname ? | 20:18 |
| ams_cs | lifeless: not sure, I'll have to wait and see if it fails again | 20:19 |
| ams_cs | lifeless: currently 37% ..... | 20:19 |
| dchilton | lifeless: yup. | 20:20 |
| dchilton | but only @ launchpad, it seems ... if i wget http://ip_address from elsewhere, no issues. | 20:21 |
| * dchilton thinks a heavy, blunt 'computer repair tool' is called for ... | 20:21 | |
| lifeless | dchilton: I'm not sure how to diagnose this | 20:23 |
| lifeless | if 'host launchpadlibrarian.net' works | 20:23 |
| lifeless | then your network can resolve it correctly | 20:23 |
| lifeless | and its a local issue | 20:23 |
| dchilton | lifeless: sounds reasonable ... but a local launchpad-specific issue? rather weird, no? | 20:24 |
| lifeless | indeed | 20:24 |
| lifeless | strace might help | 20:24 |
| lifeless | or maybe its your libproxy patch or something | 20:24 |
| dchilton | lifeless: doubt it, but who knows. got some things to try. gonna clear every dns-related cache i can find, and do this stepwise. thanks. | 20:25 |
| ams_cs | lifeless: upload failed again. no oops code, just the normal zero info page. | 20:32 |
| ams_cs | lifeless: could it be my 0.5Mb upload speed causing a timeout? | 20:33 |
| lifeless | ams_cs: can you get a screenshot of it ? | 20:33 |
| ams_cs | lifeless: did you get the file transfer notification? | 20:36 |
| lifeless | ams_cs: the what now? | 20:37 |
| ams_cs | lifeless: Xchat has a "Send File" option on the context menu attached to your name. It claims to be offerring you a file, although you're clearly not downloading it | 20:38 |
| lifeless | ah | 20:38 |
| lifeless | IRC file transfer is a terrible idea | 20:38 |
| lifeless | firewalled off for security. | 20:38 |
| ams_cs | lifeless: any other suggestions how to post an image? | 20:39 |
| lifeless | ams_cs: attach it to https://bugs.launchpad.net/launchpad/+bug/194558 | 20:39 |
| ubot5 | Ubuntu bug 194558 in Launchpad itself "Project file uploads time-out but don't OOPS" [Critical,Triaged] | 20:39 |
| ams_cs | lifeless: done | 20:41 |
| lifeless | ams_cs: ok, I believe that that is ha_proxy | 20:43 |
| lifeless | which fits our current theory of the issue | 20:43 |
| lifeless | after you upload the file, it has to be uploaded again internally | 20:43 |
| ams_cs | How can I get around it? | 20:43 |
| lifeless | make your releases smaller | 20:43 |
| lifeless | >< | 20:43 |
| lifeless | this is critical and escalated | 20:43 |
| ams_cs | yeah, the bazaar guys said the same about our sourcebase | 20:44 |
| lifeless | its one of what, 8 or so bugs we're working on as a top priority | 20:44 |
| ams_cs | my next experiment was going to be to upload it to another location, and then push it to LP from there at a faster rate. Is that likely to make a difference? | 20:45 |
| lifeless | I don't htink it will | 20:45 |
| lifeless | what happens is this | 20:45 |
| lifeless | you upload to apache | 20:45 |
| lifeless | apache opens a connection to haproxy | 20:45 |
| lifeless | ha proxy to launchpad | 20:45 |
| lifeless | while you upload it streams through these three systems | 20:46 |
| lifeless | launchpad buffers it on the appserver. | 20:46 |
| lifeless | then at the end of the upload, haproxy starts a 20 second timer | 20:46 |
| lifeless | the appserver starts uploading it to the librarian immediately. | 20:46 |
| lifeless | That takes (e.g.) 21 seconds | 20:46 |
| lifeless | haproxy says 'fail' and shows that brief error | 20:46 |
| lifeless | then the appserver finishes the upload, and it goes to record it, but the timeout code kicks in, and it errors in the appserver too. | 20:48 |
| ams_cs | hum, we've been uploading releases this size every month for months now | 20:49 |
| lifeless | yes, you can see that any variation in the datacentre performance can take you across that critical timing window | 20:49 |
| lifeless | we've had this bug report open for a while | 20:49 |
| lifeless | only recently identified it as systemic and promoted it to high-priority | 20:49 |
| lifeless | is your LP user id ams_cs ? | 20:50 |
| ams_cs | phone | 20:50 |
| lifeless | ah, ams-code* will find it | 20:50 |
| lifeless | OOPS-4b0ab86f20d7ed924c038bb819ae2172 | 20:51 |
| ubot5 | https://lp-oops.canonical.com/oops.py/?oopsid=4b0ab86f20d7ed924c038bb819ae2172 | 20:51 |
| lifeless | nope, thats just a timeout :( | 20:54 |
| lifeless | still looking | 20:54 |
| ams_cs | lifeless: back now, yes my username is ams-codesourcery | 20:59 |
| lifeless | I'm doing a search to see if there is any evidence about the server side behaviour | 21:00 |
| ams_cs | lifeless: the upload has just completed | 21:12 |
| lifeless | ams_cs: congrats | 21:12 |
| ams_cs | lifeless: I uploaded it to another machine, as I said. from there it only took 20 seconds or so (instead of 20 mins from my machine) and worked first time | 21:13 |
| lifeless | ams_cs: I'm fairly sure upload speed doesn't count into this | 21:13 |
| lifeless | ams_cs: tell me something though, if you can | 21:13 |
| ams_cs | could be just coincidence | 21:14 |
| lifeless | ams_cs: after your browser stopped sending content, how long before the error appears | 21:14 |
| ams_cs | lifeless: errr, not long, it's not instantaneous though. hard to tell what else is going on in the background. maybe 10 seconds. I wasn't really timing it | 21:15 |
| lifeless | ams_cs: thanks | 21:15 |
| lifeless | ams_cs: that helps | 21:15 |
| ams_cs | lifeless: oh one other difference: my local upload was from Chrome; my remote upload was from Firefox | 21:16 |
| ams_cs | chrome 16.0.912.59 beta vs. firefox 3.6.22 | 21:17 |
| lifeless | the only timeout oopses I've found for you so far | 21:18 |
| lifeless | are on a merge proposal | 21:18 |
| lifeless | ams_cs: 3 timeouts affected you today | 21:22 |
| lifeless | ams_cs: none matching the upload >< | 21:22 |
| ams_cs | I had some timeouts viewing bazaar history | 21:23 |
| lifeless | they aren't instrumented yet | 21:24 |
| lifeless | I might get that done today | 21:24 |
| lifeless | so we have data. | 21:24 |
| ams_cs | bzr timeouts? | 21:25 |
| ams_cs | we get lots of those. bzr hates gcc | 21:25 |
| poolie | on what page? | 21:26 |
| ams_cs | https://code.launchpad.net/gcc-linaro - "This branch has not been scanned yet" means it timedout trying to do it. | 21:26 |
| ams_cs | none of the merge requests or branch pages have working diffs either | 21:27 |
| ams_cs | poolie: it's not really bzr but launchpad being impatient I think, but bzr does make a meal of it | 21:28 |
| Forage | launchpad allows you to copy packages from specific ppa's, though I can't seem to find a way to copy an older release of a package released by a ppa. Is this possible to do somehow? | 21:29 |
| poolie | if it's been replaced in that ppa, it's | 21:30 |
| poolie | gnoe | 21:30 |
| poolie | *gone | 21:30 |
| lifeless | Forage: I don't think we have a UI for that | 21:30 |
| Forage | darn... | 21:31 |
| lifeless | poolie: not entirely :) | 21:31 |
| lifeless | poolie: they do go from the archive, thats for sure | 21:31 |
| Forage | is some URL trickery possible? | 21:31 |
| lifeless | Forage: not to do a copy | 21:31 |
| lifeless | Forage: you may be able to dig around and find the old package files though | 21:32 |
| Forage | I'd like to get the following package: https://launchpad.net/~telepathy/+archive/ppa/+build/2846124 | 21:32 |
| lifeless | Forage: should just be able to wget those debs | 21:32 |
| Forage | and then re-upload them? | 21:33 |
| lifeless | well, you can get the source package and reupload it yes | 21:33 |
| Forage | would that require me changing the version as well? | 21:33 |
| lifeless | the binaries will have to rebuild in the new ppa | 21:33 |
| lifeless | it shouldn't | 21:33 |
| wgrant | Forage: On the usual copy page (+copy-packages), search for Superseded packages. | 21:34 |
| wgrant | Forage: We delete them after a week or so, but if they're recent you can still copy them. | 21:35 |
| Forage | as far as I can tell they are gone then: https://launchpad.net/~telepathy/+archive/ppa/+copy-packages | 21:35 |
| Forage | no mention of Superseded | 21:36 |
| wgrant | Forage: There's a filter at the top | 21:36 |
| wgrant | Change Published to Superseded. | 21:36 |
| Forage | ah! | 21:36 |
| wgrant | The binaries are still shown on the build page, so it should be copiable. | 21:36 |
| Forage | lovely, it is! | 21:37 |
| Forage | cheers | 21:37 |
| Forage | sorry, launchpad is a bit of a maze to me | 21:37 |
| nuclearbob | is this the right place for questions about the launchpad api? | 21:45 |
| wgrant | nuclearbob: It is indeed. | 21:45 |
| nuclearbob | wgrant: super. I'm trying to find out how to get the reporter of a bug once I've got the url or resource for the bug | 21:46 |
| wgrant | nuclearbob: The' | 21:47 |
| wgrant | Er | 21:47 |
| wgrant | That's bug.owner | 21:47 |
| wgrant | Not to be confused with bug_task.owner, which is the creator of a specific task. | 21:48 |
| wgrant | They'll be the same for bugs with a single task, but may be different if there are multiple tasks. | 21:48 |
| nuclearbob | so if I create a bug, and then it gets assigned to someone else, bug.owner is me, but bug_task.owner is the new assignee? | 21:49 |
| wgrant | No. bug_task.assignee is the new assignee. bug_task.owner is still you. | 21:50 |
| nuclearbob | okay, thanks | 21:50 |
| wgrant | But if I come along to that bug and say it also affects dpkg in Ubuntu, the dpkg in Ubuntu task's owner is me. | 21:50 |
| nuclearbob | okay, good to know | 21:52 |
| Forage | I'm a bit lost on the version numbering of a package. Suppose there's now a version 1.2.3-0ubuntu1 provided by ubuntu. I want to update to a newer upstream release. Should I version it 1.2.4-0ppa1, 1.2.4-1ppa1 or 1.2.4-0ubuntu1ppa1? | 22:02 |
| wgrant | Forage: 1.2.4-0ppa1 | 22:02 |
| wgrant | Forage: The first number after the - is the Debian version. | 22:02 |
| wgrant | For a package that's not in Debian, that's always -0. | 22:03 |
| Forage | ah, ok | 22:03 |
| wgrant | -0ubuntu1 is the first Ubuntu version. -0ubuntu1ppa1 is greater than that, which you don't want. | 22:03 |
| wgrant | Because an official Ubuntu version should probably supersede your package. | 22:03 |
| Forage | I was in doubt because I was not sure 1.2.4-0ppa1 would get replaced by 1.2.4-0ubuntu1 | 22:04 |
| Forage | if ubuntu happens to do the update later on | 22:05 |
| Forage | how long does it take for a dput ppa upload to show up on the site? | 22:14 |
| wgrant | Forage: Up to 5 minutes. | 22:15 |
| Forage | ok, cool. Too short for a game of HoN though :-( | 22:15 |
| wgrant | Heh | 22:15 |
| Forage | ah, the building will take longer | 22:16 |
| wgrant | Yeah, the queues are a bit long at the moment. | 22:16 |
| wgrant | See /topic :) | 22:16 |
| mtaylor | I'm trying to get translations importing set up for a python project which does not store the .pot file in the tree | 22:40 |
| mtaylor | I've done that for another project - but I have no recollection of _how_ | 22:41 |
| Resistance | hmm | 23:10 |
| Resistance | anyone know why an amd64 build would be processed faster than an i386 build? | 23:10 |
| mwhudson | _all packages are built on i386 (i think?) so they can be more loaded | 23:11 |
| wgrant | Right. | 23:12 |
| Resistance | wow, really? it took almost an hour and a half to compile php5(backport i'm doing) ? | 23:12 |
| Resistance | geez | 23:12 |
| Resistance | ah that explains why the _all packages i have were only built on an i386 builder | 23:12 |
| mwhudson | oh you mean build time vs waiting time? | 23:17 |
| Resistance | no actually | 23:19 |
| Resistance | (although i am amazed at how long it took for php5.5 to actually build ;P) | 23:19 |
| mwhudson | the queue is estimated at 11 hours currently so don't complain too much about 1.5 hours :) | 23:20 |
| Resistance | well the thing was in the builders for over 24 hours before it built, and then dep-waited. | 23:22 |
| Resistance | it took almost another 24 to actually get to the amd64 build | 23:22 |
| Resistance | (thankfuloly its running the i386 build now) | 23:22 |
| Resistance | so overall, it was in the queue for 40 hours before it started getting processed at all | 23:23 |
| mwhudson | ugh | 23:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!