/srv/irclogs.ubuntu.com/2013/10/09/#launchpad.txt

=== 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
madaHello. 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 appreciated10:33
cjwatsonmada: Which PPA?10:34
mada_my ppa is ChannelGrabber PPA10:36
cjwatsonmada_: And your Launchpad username?10:43
mada_What purpose do you need my username for?10:48
cjwatsonmada_: Because if you want me to investigate your problem I need to look at the PPA11:10
cjwatsonmada_: And you haven't given me a link to it ...11:11
cjwatsonhttps://launchpad.net/~channelgrabber/+archive/ppa perhaps?11:11
mada_Apologies. Yep that's correct. Package php511:12
cjwatsonmada_: From what I can tell from the logs, you copied it once without binaries and once with binaries11:14
mada_yep11:14
cjwatsonAnd the second entries correspond to the without-binaries copy11:14
cjwatsonIt would appear that the package isn't buildable in your PPA alone, apparently due to lack of libgd-dev11:15
mada_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
cjwatsonIt's a bit weird that the builds from the without-binaries copy haven't been superseded, but it's harmless11:16
cjwatsonYou could just leave it alone, since the binary packages are in fact published in your PPA11:16
cjwatsonYes, it looks that way11:17
mada_is there any way to delete those uneeded builds then?11:17
cjwatsonI don't think so, but they should stop showing up once the amd64 one builds11:18
cjwatsonI'll score it up so that that happens ASAP11:18
cjwatsonI mean, they'll still show up when you expand that package, but they'll stop showing on the summary +packages view11:18
mada_awesome, thanks very much for your help and scoring it up11:19
cjwatsonBuilding now, which will presumably depwait, let's see11:19
cjwatsonHm, so that's done but those now show as spurious failures11:21
mada_yeah. So the package still shows as build failed even though there are working builds. Any ideas what I can do?11:27
cjwatsonI 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 binaries11:27
cjwatson)11:27
cjwatsonI don't think there's anything you or I can do about it without code changes11:27
cjwatsonWould 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
cjwatsonOh, wait11:28
cjwatsonhttps://bugs.launchpad.net/launchpad/+bug/68269211:28
ubot5Ubuntu bug 682692 in Launchpad itself "Some PPAs have duplicated builds" [High,Triaged]11:28
cjwatsonI've left a comment mentioning this situation11:30
wgrantBug #527550 is also somewhat related11:32
ubot5bug 527550 in Launchpad itself "CopyChecker._checkArchiveConflicts erroneously permits copies of sources with failed and unpublished builds" [High,Triaged] https://launchpad.net/bugs/52755011:32
wgrantI think11:32
mada_ok, thanks guys11:33
cjwatsonWe could definitely do better with the build status summaries here11:33
wgrantBut the second copy should probably have been rejected because of the conflicting builds in the target, even if they were failed.11:33
cjwatsonPerhaps that's a separate bug independent of the copy bugs11:33
mada_Are there any even temporary solutions to let me install this package from my ppa?11:40
mada_for the time being11:40
cjwatsonmada_: None of these problems have the slightest effect on that; as I said earlier, the builds are already published in the channelgrabber PPA11:41
cjwatsonYou should already be able to install them11:42
mada_Ok, I see. Thank you again for your time11:45
cjwatsonno problem11:45
=== 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
mada_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 PPA14:29
cjwatsonmada_: Can I have an example "apt-get install" line?14:35
cjwatsonmada_: 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:42
cjwatsonmada_: 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
cjwatsonmada_: There may well be more such (for example I expect that php-json in turn requires json-c)14:43
mada_cjwatson: Thanks, I will go investigate14:51
=== 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
saiarcot895Could 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/507384319:13
saiarcot895That build occurred first on October 4, then twice on October 9, but I didn't ask for a rebuild19:14
dobeywhat do you mean?19:17
dobeylooks fine to me19:18
saiarcot895I 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 back19:21
dobeythat's not what it says19:51
dobeyoh wait, was looking at the saucy build just now19:52
dobeysaiarcot895: 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 rebuild19:53
dobeythat is normal and correct behavior19:54
dobeybut 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 others19:55
TheLordOfTimeif 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
TheLordOfTime(this might need to be asked in an ubuntu-specific channel though...)19:58
dobeyTheLordOfTime: yes. but "build-test" PPAs are frowned upon. one should use sbuild to test builds locally, for example20:00
TheLordOfTimedobey: i already did that, i have two sets of building: pbuilder locally, testbuild after that succeds20:00
TheLordOfTimedobey: 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
TheLordOfTimebut thanks.20:01
dobeyand 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"20:01
=== jml__ is now known as jml
cjwatsonI 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:44
dobeysure20:49
dobeyi think that's a fair bit different than the simple "test that stuff builds" usage though20:49
cjwatsonAnd 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:49
dobeyright, 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 copy20:55
cjwatsonIndeed.20:59
cjwatsonThe main objection to test builds on LP is that it's a waste of resources, though - so.21:00
dobeyright21:01
philsfI'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)" error22:23
philsfI followed the steps from http://doc.bazaar.canonical.com/beta/en/mini-tutorial/index.html22:23
philsfssh -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/mistake22:25
philsfI 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.22:42

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!