[06:20] <ehoover> could someone help me with a launchpad recipe problem? ( https://code.launchpad.net/~ehoover/+recipe/wine-compholio ).  i was able to build successfully locally, but the build farm doesn't like it.
[06:21] <StevenK> "File wine-compholio_1.7.0.orig.tar.gz already exists in compholio, but uploaded version has different contents."
[06:21] <ehoover> StevenK: that's autogenerated, i didn't make that
[06:23] <StevenK> ehoover: None of the recipe builds uploaded correctly since the file already existed so you uploaded it automatically?
[06:24] <ehoover> StevenK: the recipe created  wine-compholio_1.7.0.orig.tar.gz - i don't know how i have any control over it.
[06:25] <StevenK> ehoover: You have 4 packages of wine-compholio already in your PPA
[06:26] <ehoover> StevenK: i'm trying to update to using a recipe instead of manually uploading the packages, it seems to generate the correct version info for everything except the upstream tarball
[06:27] <ehoover> so since it made "wine-compholio - 1.7.0-2~quantal1" it doesn't appear to want to build the others
[06:27] <wgrant> ehoover: Recipes generate the orig.tar.gz from pristine-tar information stored in the branches.
[06:27] <ehoover> even though the upstream tarball is identical
[06:27] <wgrant> It sounds like the orig.tar.gz in the branch is different from the one you uploaded to your PPA separately.
[06:28] <wgrant> And a PPA can't have two files with the same name and version but different contents.
[06:28] <wgrant> You'll need to change the version number of the orig tarball.
[06:28] <ehoover> wgrant: but i didn't name the orig tarball, it did that automatically
[06:29] <StevenK> ehoover: An orig will be named with the upstream version, which strips off the dash and everything past that
[06:29] <StevenK> So 1.7.0-2 is still 1.7.0
[06:30] <ehoover> StevenK: so, since i uploaded a 1.7.0<ish> previously - even though i didn't upload an orig tarball with that code - it won't let me upload a new one?
[06:30] <wgrant> Your recipe's version template is '{debversion}', which means it will just use the latest version from the changelog.
[06:31] <StevenK> ehoover: An orig tarball had to come from somewhere originally :-)
[06:31] <wgrant> https://launchpadlibrarian.net/148135917/wine-compholio_1.7.0-2~quantal1_source.changes
[06:31] <ehoover> StevenK: before i used to unpack the tarball on my end
[06:31] <wgrant> There was an orig.tar.gz on that upload.
[06:31] <wgrant> Oh, that was from a recipe.
[06:32] <ehoover> wgrant: yes, that was from this same upload
[06:32] <ehoover> so quantal worked, but none of the other ones did
[06:32] <wgrant> ehoover: What's the SHA-1 hash of the orig.tar.gz generated when you build the recipe locally?
[06:33] <ehoover> i tried a second time (for everyone except quantal) since DarkPlayer suggested that the first upload might break
[06:33] <ehoover> 19e4c888d9d95cacb275b326d3dc3dd59ecaf509  wine-compholio_1.7.0.orig.tar.gz
[06:34] <wgrant>  f115f7da1ab5098ef6804fbc0afaf83d8e6d5485 21165497 wine-compholio_1.7.0.orig.tar.gz
[06:36] <wgrant> Huh
[06:36] <wgrant> Why does one of those branches just have a wine tarball in it?
[06:37] <ehoover> wgrant: just tried twice, if i rebuild it locally (same recipe) it generates the same sha1sum
[06:37] <ehoover> wgrant: because i couldn't get it to include the upstream tarball any other way
[06:38] <ehoover> wgrant: note that the filesize is apparently different (?), locally i get 21165464 instead of 21165497
[06:39] <ehoover> wgrant: even if i put it in a separate folder and tagged only that folder with the upstream revision it would include that entire revision in the ".orig" tarball
[06:40] <wgrant> Well, pristine-tar is designed to construct a tarball from a branch whose tree roughly matches the tarball contents.
[06:40] <wgrant> This should still work, and it's quite possibly a bug in the old pristine-tar that's on the buildds, but it's also a really weird way of getting an orig tarball.
[06:40] <ehoover> wgrant: well, if i could tell it "download the wine tarball from ibiblio" i would
[06:41] <ehoover> there didn't seem to be a way to do that :/
[06:41]  * ehoover was highly disappointed
[06:43] <wgrant> Recipes are specifically designed to work from branches.
[06:44] <wgrant> If you wanted to work from an upstream tarball you'd normally use 'bzr import-upstream' or 'bzr merge-upstream' to import the tarball's contents into a branch.
[06:45] <ehoover> wgrant: that seems rather restrictive, especially since it wasn't clear that i'd break an entire version number by using a tarball instead of the unpacked data
[06:45] <wgrant> Because now you have a tarball in your PPA that looks like a wine 1.7.0 upstream tarball, except that it is a tarball containing the wine 1.7.0 upstream tarball.
[06:45] <wgrant> ehoover: The breakage is not directly related, I don't think.
[06:46] <wgrant> But it's not exactly restrictive; recipes are what you use when you want to turn a set of branches into a package.
[06:46] <wgrant> They're not what you use when you don't have branches.
[06:46] <wgrant> They were designed just for the use case of having branches and wanting a package.
[06:47] <ehoover> wgrant: well, i want a package of my changes to a non-branched package ;)
[06:48] <ehoover> wgrant: i mean, i could go back to uploading all the packages separately - but this recipe system seems really slick
[06:50] <ehoover> wgrant: is there a way for me to see the contents of wine-compholio_1.7.0.orig.tar.gz on the build farm? maybe it's putting different stuff in there from when i execute the recipe locally
[06:51] <wgrant> ehoover: You can find the one that quantal used by expanding the package on https://code.launchpad.net/~ehoover/+archive/compholio/+packages
[06:51] <wgrant> It has the same file inside it.
[06:52] <wgrant> I'd expect pristine-tar to check the hash of the reconstructed tarball, but I don't know for sure that it does.
[06:54] <ehoover> wgrant: weird, the _contents_ of the tarball have the same sum - but the tarball itself has a different sum
[06:55] <ehoover> and since there's only one file it's not like the files are in a different order O.o
[06:55] <wgrant> Sure, but they can compress differently.
[06:55] <wgrant> Or have a different timestamp.
[06:55] <wgrant> But pristine-tar would usually fail in that situation.
[06:56] <ehoover> wgrant: but why do they compress the same even if i re-run it on my end (even choosing a new working directory)?
[06:56] <ehoover> (and have the same timestamp)
[06:56] <wgrant> pristine-tar stores enough information to reconstruct an identical tarball.
[06:57] <ehoover> wgrant: hmm, well - clearly i don't understand enough about how this system works to make it do what i want.  could you please provide me with a suggestion?
[07:09] <wgrant> ehoover: Um, let's see.
[07:09] <ehoover> wgrant: note: currently seeing if i can manually upload using the original .orig
[07:10] <wgrant> You should be able to.
[07:13] <wgrant> ehoover: So, the way you'd normally do this is to create an upstream branch, the contents of which is just the extracted upstream tarball. 'bzr import-upstream' imports it the right way.
[07:13] <wgrant> Then you'd create a branch of the upstream branch, and add the packaging in that one.
[07:14] <wgrant> bzr builddeb will then reconstruct the real upstream tarball.
[07:14] <ehoover> wgrant: well, i've probably broken that now
[07:14] <ehoover> since it will generate the same 1.7.0 tarball
[07:14] <ehoover> but with a different hash
[07:14] <wgrant> Now, in this case you've cursed the 1.7.0 version forever with an incorrect tarball, yes.
[07:14] <wgrant> So you'd need to use something like 1.7.0+really
[07:16] <wgrant> bzr builddeb generates the orig.tar.gz from the 'upstream-VERSION' tag.
[07:16] <wgrant> So in this case it looks for upstream-1.7.0
[07:17] <wgrant> But you need to use a different version, so either give the tarball a different version when you import it, or alias it afterwards with "bzr tag upstream-1.7.0+really -rtag:upstream-1.7.0"
[07:33] <ehoover> wgrant: thanks for the help, i'm giving up for now
[07:34] <ehoover> i'll make sure not to use tarballs inside the branch in the future
[11:11] <dowson_> Hi, I'm trying to setup launchpad locally on my machine using the steps outlined in https://dev.launchpad.net/Running on a Ubuntu 12.04 virtual machine, but I'm running in trouble with the requests getting redirected. Is there anyway to disable re-direction?
[11:11] <dowson_> Making local branch of Launchpad trunk, this may take a while...
[11:11] <dowson_> You have not informed bzr of your Launchpad ID, and you must do this to
[11:11] <dowson_> write to Launchpad or access private data.  See "bzr help launchpad-login".
[11:11] <dowson_> bzr: ERROR: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/.bzr/repository/packs/676c7a2c6bf9b928a6d4a14d1fd37084.pack is redirected to http://91.74.184.65:80/videoplayer/676c7a2c6bf9b928a6d4a14d1fd37084.pack?ich_u_r_i=5ba889d5a1871a26dbdcc286688a8d24&ich_s_t_a_r_t=0&ich_e_n_d=0&ich_k_e_y=1345088922751163062440&ich_t_y_p_e=1&ich_d_i_s_k_i_d=4&ich_u_n_i_t=1
[11:11] <dowson_> ERROR: Unable to create local copy of Rocketfuel trunk
[11:51] <StevenK> dowson_: That's very very strange. I don't think we'd redirect pack files to an Emirates IP address ...
[12:04] <dowson_> I'm located in Dubai, UAE, so for some reason the files are being redirected to some server in the UAE.
[12:04] <StevenK> dowson_: I might suggest using bzr+ssh then
[12:04] <dowson_> I started off with a clean install of Ubuntu-12.04 on a VMware image.
[12:05] <dowson_> I had installed ssh, but how do I get bzr to use ssh?
[12:07] <StevenK> dowson_: You need to generate a key using ssh-keygen, then you need to tell Launchpad about the public key -- bzr should then use it when you branch
[12:11] <dowson_> is the ssh key to be stored on the bazaar server, i.e. I have to create an account on the public bazaar server?
[12:13] <StevenK> dowson_: It's a Launchpad account
[13:11] <dowson_> StevenK: I configured SSH and uploaded my public keys to the launchpad server. It still attempts to re-direct it to that same server!!
[13:11] <dowson_> The authenticity of host 'bazaar.launchpad.net (91.189.95.84)' can't be established.
[13:11] <dowson_> RSA key fingerprint is 9d:38:3a:63:b1:d5:6f:c4:44:67:53:49:2e:ee:fc:89.
[13:19] <dobey> dowson_: that's a different IP. that is the correct IP for bazaar.launchpad.net
[13:20] <dobey> if you want bazaar.launchpad.net to point at your local instance, you need to configure your /etc/hosts or something to point it at the local server
[13:27] <dowson_> I'm just in the process of setting up launchpad, so it hasn't copied the sources yet. So, I should complete the install first, locally, correct? and then later on, point it to my local server.
[13:28] <dobey> which server are you expecting bzr to connect to exactly?
[13:29] <dobey> also i think you should probably ask in #launchpad-dev, as this channel is more for general help with the launchpad.net instance of launchpad. -dev is more for development stuff (which setting up a local dev instance falls under)
[13:29] <dowson_> ok
[13:47] <dowson_> Just to let you know, after I configured for SSH, registered my public SSH keys with the launchpad.net server, and accepted the server RSA finger print, it's fetching the sources correctly.
[13:48] <dowson_> The notice that the IP address of the server without SSH is different from the one with SSH access.
[18:27] <XandriX> anyone had this issue on windows where the msp debug interface shows up as a usb input device instead of loading its proper driver ?
[18:27] <dobey> what does that have to do with launchpad.net?
[18:28] <XandriX> omfg
[18:28] <XandriX> wrong channel join haha
[18:29] <XandriX> sorry guys
[18:29] <XandriX> have a good one
[21:10] <DarkPlayer> hi, is it possible to split up a bug in launchpad? i have some users who simply start posting new problems in old bug reports , so it is possible to create a new bug report from the new posts?
[21:12] <Logan_> DarkPlayer: I don't believe that's currently possible, but you can definitely request it: https://bugs.launchpad.net/launchpad/+filebug
[21:15] <dobey> DarkPlayer: no, it's not possible
[21:16] <DarkPlayer> k
[21:16] <dobey> i don't think it's possible on any bug tracker to do that
[21:16] <dobey> at least, not dierctly. you can of course always copy/paste stuff into a new bug
[21:17] <dobey> it's better to just try and inform/train your users to always file new bugs
[21:23] <broder> hmm. i just had a private i386 ppa build run (and fail) on chindi03, which is identified as an arm ppa builder
[21:23] <broder> that...seems wrong
[21:23] <broder> in a couple ways
[21:23] <dobey> broder: why? qemu builds arm stuff on i386 hosts, iirc
[21:24] <broder> err, but this wasn't an arm build
[21:24] <broder> and (unless something changed) i thought i wasn't allowed to do arm builds in ppas at all
[21:25] <dobey> i didn't say it was an arm build
[21:25] <broder> i see
[21:25] <broder> it also exploded in ways i'm not used to
[21:25] <broder> parsing the sbuildrc
[21:26] <dobey> anyway "identifies as" and "labelled as" aren't necessarily the same thing. it does say "(arm ppa builder)" for that host, but it's certainly building for i386
[21:26] <dobey> so it's labelled as arm, but identified as i386, i would say
[21:27] <dobey> but irrelevant to your issue, which is a host config issue
[21:27] <dobey> just resubmit your build and hopefully it'll land on another builder that isn't broken
[21:27] <dobey> unless someone is around that can take that builder off the loop for now
[21:27] <dobey> (i can't)
[21:28] <dobey> anyway, i'm leaving now. so later :)
[21:57] <wgrant> broder: All the PPA ARM builders are actually using qemu-user-static on amd64 hosts
[21:57] <wgrant> The arm bit in the description just means they're configured as qemu-capable.
[21:57] <broder> ha. cute
[21:57] <broder> ok, so sounds like the builder was just generically unhappy then
[21:57] <wgrant> Yeah, that one is.
[21:57] <wgrant> Am fixing.
[21:57] <broder> awesome, thanks
[21:57] <wgrant> Thanks for letting us know.