=== 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 [06:20] 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] "File wine-compholio_1.7.0.orig.tar.gz already exists in compholio, but uploaded version has different contents." [06:21] StevenK: that's autogenerated, i didn't make that [06:23] ehoover: None of the recipe builds uploaded correctly since the file already existed so you uploaded it automatically? [06:24] 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] ehoover: You have 4 packages of wine-compholio already in your PPA [06:26] 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] so since it made "wine-compholio - 1.7.0-2~quantal1" it doesn't appear to want to build the others [06:27] ehoover: Recipes generate the orig.tar.gz from pristine-tar information stored in the branches. [06:27] even though the upstream tarball is identical [06:27] It sounds like the orig.tar.gz in the branch is different from the one you uploaded to your PPA separately. [06:28] And a PPA can't have two files with the same name and version but different contents. [06:28] You'll need to change the version number of the orig tarball. [06:28] wgrant: but i didn't name the orig tarball, it did that automatically [06:29] ehoover: An orig will be named with the upstream version, which strips off the dash and everything past that [06:29] So 1.7.0-2 is still 1.7.0 [06:30] StevenK: so, since i uploaded a 1.7.0 previously - even though i didn't upload an orig tarball with that code - it won't let me upload a new one? [06:30] Your recipe's version template is '{debversion}', which means it will just use the latest version from the changelog. [06:31] ehoover: An orig tarball had to come from somewhere originally :-) [06:31] https://launchpadlibrarian.net/148135917/wine-compholio_1.7.0-2~quantal1_source.changes [06:31] StevenK: before i used to unpack the tarball on my end [06:31] There was an orig.tar.gz on that upload. [06:31] Oh, that was from a recipe. [06:32] wgrant: yes, that was from this same upload [06:32] so quantal worked, but none of the other ones did [06:32] ehoover: What's the SHA-1 hash of the orig.tar.gz generated when you build the recipe locally? [06:33] i tried a second time (for everyone except quantal) since DarkPlayer suggested that the first upload might break [06:33] 19e4c888d9d95cacb275b326d3dc3dd59ecaf509 wine-compholio_1.7.0.orig.tar.gz [06:34] f115f7da1ab5098ef6804fbc0afaf83d8e6d5485 21165497 wine-compholio_1.7.0.orig.tar.gz [06:36] Huh [06:36] Why does one of those branches just have a wine tarball in it? [06:37] wgrant: just tried twice, if i rebuild it locally (same recipe) it generates the same sha1sum [06:37] wgrant: because i couldn't get it to include the upstream tarball any other way [06:38] wgrant: note that the filesize is apparently different (?), locally i get 21165464 instead of 21165497 [06:39] 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] Well, pristine-tar is designed to construct a tarball from a branch whose tree roughly matches the tarball contents. [06:40] 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] wgrant: well, if i could tell it "download the wine tarball from ibiblio" i would [06:41] there didn't seem to be a way to do that :/ [06:41] * ehoover was highly disappointed === jam1 is now known as jam [06:43] Recipes are specifically designed to work from branches. [06:44] 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] 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] 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] ehoover: The breakage is not directly related, I don't think. [06:46] 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] They're not what you use when you don't have branches. [06:46] They were designed just for the use case of having branches and wanting a package. [06:47] wgrant: well, i want a package of my changes to a non-branched package ;) [06:48] wgrant: i mean, i could go back to uploading all the packages separately - but this recipe system seems really slick [06:50] 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] ehoover: You can find the one that quantal used by expanding the package on https://code.launchpad.net/~ehoover/+archive/compholio/+packages [06:51] It has the same file inside it. [06:52] I'd expect pristine-tar to check the hash of the reconstructed tarball, but I don't know for sure that it does. === tasdomas_afk is now known as tasdomas [06:54] wgrant: weird, the _contents_ of the tarball have the same sum - but the tarball itself has a different sum [06:55] and since there's only one file it's not like the files are in a different order O.o [06:55] Sure, but they can compress differently. [06:55] Or have a different timestamp. [06:55] But pristine-tar would usually fail in that situation. [06:56] 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] (and have the same timestamp) [06:56] pristine-tar stores enough information to reconstruct an identical tarball. [06:57] 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] ehoover: Um, let's see. [07:09] wgrant: note: currently seeing if i can manually upload using the original .orig [07:10] You should be able to. [07:13] 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] Then you'd create a branch of the upstream branch, and add the packaging in that one. [07:14] bzr builddeb will then reconstruct the real upstream tarball. [07:14] wgrant: well, i've probably broken that now [07:14] since it will generate the same 1.7.0 tarball [07:14] but with a different hash [07:14] Now, in this case you've cursed the 1.7.0 version forever with an incorrect tarball, yes. [07:14] So you'd need to use something like 1.7.0+really [07:16] bzr builddeb generates the orig.tar.gz from the 'upstream-VERSION' tag. [07:16] So in this case it looks for upstream-1.7.0 [07:17] 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] wgrant: thanks for the help, i'm giving up for now [07:34] i'll make sure not to use tarballs inside the branch in the future === mpt_ is now known as mpt [11:11] 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] Making local branch of Launchpad trunk, this may take a while... [11:11] You have not informed bzr of your Launchpad ID, and you must do this to [11:11] write to Launchpad or access private data. See "bzr help launchpad-login". [11:11] 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] ERROR: Unable to create local copy of Rocketfuel trunk [11:51] dowson_: That's very very strange. I don't think we'd redirect pack files to an Emirates IP address ... [12:04] I'm located in Dubai, UAE, so for some reason the files are being redirected to some server in the UAE. [12:04] dowson_: I might suggest using bzr+ssh then [12:04] I started off with a clean install of Ubuntu-12.04 on a VMware image. [12:05] I had installed ssh, but how do I get bzr to use ssh? [12:07] 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] 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] dowson_: It's a Launchpad account [13:11] 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] The authenticity of host 'bazaar.launchpad.net (91.189.95.84)' can't be established. [13:11] RSA key fingerprint is 9d:38:3a:63:b1:d5:6f:c4:44:67:53:49:2e:ee:fc:89. [13:19] dowson_: that's a different IP. that is the correct IP for bazaar.launchpad.net [13:20] 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 === Guest76202 is now known as nesthib === Ursinha is now known as Ursinha-afk [13:27] 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] which server are you expecting bzr to connect to exactly? [13:29] 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] ok === Ursinha-afk is now known as Ursinha [13:47] 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] The notice that the IP address of the server without SSH is different from the one with SSH access. === 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 [18:27] 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] what does that have to do with launchpad.net? [18:28] omfg [18:28] wrong channel join haha [18:29] sorry guys [18:29] have a good one [21:10] 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] DarkPlayer: I don't believe that's currently possible, but you can definitely request it: https://bugs.launchpad.net/launchpad/+filebug [21:15] DarkPlayer: no, it's not possible [21:16] k [21:16] i don't think it's possible on any bug tracker to do that [21:16] at least, not dierctly. you can of course always copy/paste stuff into a new bug [21:17] it's better to just try and inform/train your users to always file new bugs [21:23] hmm. i just had a private i386 ppa build run (and fail) on chindi03, which is identified as an arm ppa builder [21:23] that...seems wrong [21:23] in a couple ways [21:23] broder: why? qemu builds arm stuff on i386 hosts, iirc [21:24] err, but this wasn't an arm build [21:24] and (unless something changed) i thought i wasn't allowed to do arm builds in ppas at all [21:25] i didn't say it was an arm build [21:25] i see [21:25] it also exploded in ways i'm not used to [21:25] parsing the sbuildrc [21:26] 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] so it's labelled as arm, but identified as i386, i would say [21:27] but irrelevant to your issue, which is a host config issue [21:27] just resubmit your build and hopefully it'll land on another builder that isn't broken [21:27] unless someone is around that can take that builder off the loop for now [21:27] (i can't) [21:28] anyway, i'm leaving now. so later :) [21:57] broder: All the PPA ARM builders are actually using qemu-user-static on amd64 hosts [21:57] The arm bit in the description just means they're configured as qemu-capable. [21:57] ha. cute [21:57] ok, so sounds like the builder was just generically unhappy then [21:57] Yeah, that one is. [21:57] Am fixing. [21:57] awesome, thanks [21:57] Thanks for letting us know. === 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