=== mars is now known as Guest6383 === stub` is now known as stub === DarkPlayer_ is now known as DarkPlayer === zenitraM^away is now known as zenitraM === czajkows1i is now known as czajkowski === jml_ is now known as jml [10:33] Hello. I am attempting to copy binaries of working package to my ppa. When I do, it shows build failed. Inside it shows multiple statuses for each architecture. AMD64 has successful build, then another entry saying dependency wait. Why does this happen? Any guidance would be appreciated [10:34] mada: Which PPA? [10:36] my ppa is ChannelGrabber PPA [10:43] mada_: And your Launchpad username? [10:48] What purpose do you need my username for? [11:10] mada_: Because if you want me to investigate your problem I need to look at the PPA [11:11] mada_: And you haven't given me a link to it ... [11:11] https://launchpad.net/~channelgrabber/+archive/ppa perhaps? [11:12] Apologies. Yep that's correct. Package php5 [11:14] mada_: From what I can tell from the logs, you copied it once without binaries and once with binaries [11:14] yep [11:14] And the second entries correspond to the without-binaries copy [11:15] It would appear that the package isn't buildable in your PPA alone, apparently due to lack of libgd-dev [11:16] ah, i chose to delete the without binaries copy of the package, but you are saying the builds are still corresponding to that package? [11:16] It's a bit weird that the builds from the without-binaries copy haven't been superseded, but it's harmless [11:16] You could just leave it alone, since the binary packages are in fact published in your PPA [11:17] Yes, it looks that way [11:17] is there any way to delete those uneeded builds then? [11:18] I don't think so, but they should stop showing up once the amd64 one builds [11:18] I'll score it up so that that happens ASAP [11:18] I mean, they'll still show up when you expand that package, but they'll stop showing on the summary +packages view [11:19] awesome, thanks very much for your help and scoring it up [11:19] Building now, which will presumably depwait, let's see [11:21] Hm, so that's done but those now show as spurious failures [11:27] yeah. So the package still shows as build failed even though there are working builds. Any ideas what I can do? [11:27] I think this is a bug (arguably that the builds should never have been created, but also that this situation shouldn't be shown on +packages as failures when the published archive in fact has those binaries [11:27] ) [11:27] I don't think there's anything you or I can do about it without code changes [11:28] Would you file a bug about this on https://bugs.launchpad.net/launchpad/ ? I've looked and don't see an existing one describing this situation. [11:28] Oh, wait [11:28] https://bugs.launchpad.net/launchpad/+bug/682692 [11:28] Ubuntu bug 682692 in Launchpad itself "Some PPAs have duplicated builds" [High,Triaged] [11:30] I've left a comment mentioning this situation [11:32] Bug #527550 is also somewhat related [11:32] bug 527550 in Launchpad itself "CopyChecker._checkArchiveConflicts erroneously permits copies of sources with failed and unpublished builds" [High,Triaged] https://launchpad.net/bugs/527550 [11:32] I think [11:33] ok, thanks guys [11:33] We could definitely do better with the build status summaries here [11:33] But the second copy should probably have been rejected because of the conflicting builds in the target, even if they were failed. [11:33] Perhaps that's a separate bug independent of the copy bugs [11:40] Are there any even temporary solutions to let me install this package from my ppa? [11:40] for the time being [11:41] mada_: None of these problems have the slightest effect on that; as I said earlier, the builds are already published in the channelgrabber PPA [11:42] You should already be able to install them [11:45] Ok, I see. Thank you again for your time [11:45] no problem === vila is now known as vila-laaaate-lun === vila-laaaate-lun is now known as vila-late-lunch === vila-late-lunch is now known as vila [14:29] cjwatson: The package does not install successfully from my PPA. It says i have unmet dependencies and lists some packages which are also in the "built packages" list on the package on launchpad (so they should be included right?). It installs correctly from the original PPA [14:35] mada_: Can I have an example "apt-get install" line? [14:42] mada_: Reproduced with "apt-get install php5-cli". apt doesn't always give the root cause immediately - you sometimes have to successively add packages it complains about as "not going to be installed" to the "apt-get install" line to persuade it to give you the real cause. [14:43] mada_: In the case of php5-cli it's because it also requires libedit and php-json from the PPA you copied php5 from. [14:43] mada_: There may well be more such (for example I expect that php-json in turn requires json-c) [14:51] cjwatson: Thanks, I will go investigate === zenitraM is now known as zenitraM^away === zenitraM^away is now known as zenitraM === zenitraM is now known as zenitraM^away === beuno_ is now known as bueno [19:13] Could someone see if something is wrong with this build (I don't mean the build log error, but the build instance itself? https://launchpad.net/~saiarcot895/+archive/flightgear-edge/+build/5073843 [19:14] That build occurred first on October 4, then twice on October 9, but I didn't ask for a rebuild [19:17] what do you mean? [19:18] looks fine to me [19:21] I published a new version of that package on October 3, and the build was shortly after attempted and failed. Then, this morning, that build occurred again and failed (as expected), but I didn't ask for a retry of that build. The same thing happened 3 hours back [19:51] that's not what it says [19:52] oh wait, was looking at the saucy build just now [19:53] saiarcot895: it's because on precise the flightgear package build failed due to a missing dependency (which made it DEPWAIT), and when that dependency was finally satisfied today, it tried to rebuild [19:54] that is normal and correct behavior [19:55] but if you expect something to fail, you shouldn't upload it to a PPA. it's a limited, shared, public service, so introducing many rebuilds that you expect to fail will only cause the service to be less reliable for yourself and others [19:58] if I have two PPAs, a build-test PPA and a actual "For Use" PPA, and I've build-tested something in the build-test, can I safely copy the binaries over to the "For Use" PPA without rebuilding, or no? Assuming the test-build PPA and the "For Use" PPA have the same dependencies and i'm not copying across releases of Ubuntu... [19:58] (this might need to be asked in an ubuntu-specific channel though...) [20:00] TheLordOfTime: yes. but "build-test" PPAs are frowned upon. one should use sbuild to test builds locally, for example [20:00] dobey: i already did that, i have two sets of building: pbuilder locally, testbuild after that succeds [20:01] dobey: that's because i don't explicitly trust pbuilder, and in 99% of the time the builds are 100% working, the only time it breaks is if debian changes something that breaks things (then requiring me to fix it) [20:01] but thanks. [20:01] and all PPAs are "for use" PPAs. there is no way to say "don't publish binaries to a real archive, and prevent users from adding this PPA" === jml__ is now known as jml [20:44] I think staging PPAs are a reasonable enough thing to use as long as you understand they're still public. In particular they can be useful to avoid arch skew in widely-used archives. [20:49] sure [20:49] i think that's a fair bit different than the simple "test that stuff builds" usage though [20:49] And if you copy binaries they aren't a waste of resources as long as you've made a reasonable effort to test-build first, as the user in question said. [20:55] right, though it wasn't asked if it was a waste of resources; just if it was "safe" to do, and copying binaries to the same series in a different PPA is certainly safe, assuming that all the deps are met with the copy [20:59] Indeed. [21:00] The main objection to test builds on LP is that it's a waste of resources, though - so. [21:01] right [22:23] I'm having a little problem pushing to lp, but I'm not sure if it's a problem with my bzr config, or my lp profile. The error I'm getting is the same as: https://answers.launchpad.net/bzr/+question/190008 basically, bzr is not authenticating via ssh to lp. I already configured an RSA key in lp, but am getting a "permission denied (publickey)" error [22:23] I followed the steps from http://doc.bazaar.canonical.com/beta/en/mini-tutorial/index.html [22:25] ssh -v philsf@bazaar.launchpad.net just cycles between my available (DSA and RSA) keys, there doesn't seem to be a (local) file permission error/mistake [22:42] I just inserted a new ssh key in lp, and now it worked. I don't understand why it refused the first one, but it's good enough for me, for now.