| === kb3gtn|away is now known as kb3gtn | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === stub` is now known as stub | ||
| === wallyworld__ is now known as wallyworld | ||
| 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:20 |
|---|---|---|
| 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:21 |
| StevenK | ehoover: None of the recipe builds uploaded correctly since the file already existed so you uploaded it automatically? | 06:23 |
| 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:24 |
| StevenK | ehoover: You have 4 packages of wine-compholio already in your PPA | 06:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| wgrant | f115f7da1ab5098ef6804fbc0afaf83d8e6d5485 21165497 wine-compholio_1.7.0.orig.tar.gz | 06:34 |
| wgrant | Huh | 06:36 |
| wgrant | Why does one of those branches just have a wine tarball in it? | 06:36 |
| 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:37 |
| ehoover | wgrant: note that the filesize is apparently different (?), locally i get 21165464 instead of 21165497 | 06:38 |
| 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:39 |
| 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:40 |
| ehoover | there didn't seem to be a way to do that :/ | 06:41 |
| * ehoover was highly disappointed | 06:41 | |
| === jam1 is now known as jam | ||
| wgrant | Recipes are specifically designed to work from branches. | 06:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| ehoover | wgrant: well, i want a package of my changes to a non-branched package ;) | 06:47 |
| ehoover | wgrant: i mean, i could go back to uploading all the packages separately - but this recipe system seems really slick | 06:48 |
| 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:50 |
| 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:51 |
| 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:52 |
| === tasdomas_afk is now known as tasdomas | ||
| ehoover | wgrant: weird, the _contents_ of the tarball have the same sum - but the tarball itself has a different sum | 06:54 |
| 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:55 |
| 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:56 |
| 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? | 06:57 |
| wgrant | ehoover: Um, let's see. | 07:09 |
| ehoover | wgrant: note: currently seeing if i can manually upload using the original .orig | 07:09 |
| wgrant | You should be able to. | 07:10 |
| 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:13 |
| 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:14 |
| 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:16 |
| 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:17 |
| ehoover | wgrant: thanks for the help, i'm giving up for now | 07:33 |
| ehoover | i'll make sure not to use tarballs inside the branch in the future | 07:34 |
| === mpt_ is now known as mpt | ||
| 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:11 |
| StevenK | dowson_: That's very very strange. I don't think we'd redirect pack files to an Emirates IP address ... | 11:51 |
| 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:04 |
| dowson_ | I had installed ssh, but how do I get bzr to use ssh? | 12:05 |
| 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:07 |
| 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:11 |
| StevenK | dowson_: It's a Launchpad account | 12:13 |
| 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:11 |
| dobey | dowson_: that's a different IP. that is the correct IP for bazaar.launchpad.net | 13:19 |
| 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:20 |
| === Guest76202 is now known as nesthib | ||
| === Ursinha is now known as Ursinha-afk | ||
| 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:27 |
| dobey | which server are you expecting bzr to connect to exactly? | 13:28 |
| 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:29 |
| === Ursinha-afk is now known as Ursinha | ||
| 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:47 |
| dowson_ | The notice that the IP address of the server without SSH is different from the one with SSH access. | 13:48 |
| === tasdomas is now known as tasdomas_afk | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === tasdomas_afk is now known as tasdomas | ||
| === tasdomas is now known as tasdomas_afk | ||
| 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:27 |
| XandriX | omfg | 18:28 |
| XandriX | wrong channel join haha | 18:28 |
| XandriX | sorry guys | 18:29 |
| XandriX | have a good one | 18:29 |
| 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:10 |
| Logan_ | DarkPlayer: I don't believe that's currently possible, but you can definitely request it: https://bugs.launchpad.net/launchpad/+filebug | 21:12 |
| dobey | DarkPlayer: no, it's not possible | 21:15 |
| 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:16 |
| dobey | it's better to just try and inform/train your users to always file new bugs | 21:17 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| dobey | anyway, i'm leaving now. so later :) | 21:28 |
| 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. | 21:57 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!