=== maclin1 is now known as maclin === maclin1 is now known as maclin === maclin1 is now known as maclin === maclin1 is now known as maclin === maclin1 is now known as maclin [09:50] I can't seem to change the upstream bug task to a Debian nis package bug task in bug 1204530. The distro list doesn't include Debian. Is this a known bug? [09:50] bug 1204530 in nis (Ubuntu) "yppasswd results in a segmentation fault when run on clients or server" [High,Confirmed] https://launchpad.net/bugs/1204530 [09:51] It's already tracking the Debian bug, just against an "upstream" instead of a "distro package" (not sure what the right terms are) [09:56] rbasak: It's only possible to move a task to a target that tracks bugs in LP. If you want a Debian task, you need to add a new task with the bug watch directly. [10:11] wgrant: ah, so add a new task and delete the upstream one? That sort of works in that I can add the Debian task, but I can't delete the upstream task as it's a project I don't have permission on. [10:11] (whereas I think I could normally move a task from upstream if it was wrong) [10:11] But that's better at least, thanks. [10:13] rbasak: I've deleted the upstream task. [10:13] Thanks! [10:14] Normally I don't care but this is a bug I want to hand to a new starter as an exercise so I'd like the bug status right so as not to confuse things. [10:19] Good idea :) === gaughen_ is now known as gaughen [18:00] hi, I'm trying to upload a 'precise' version of a package using gbp. I already have a 'trusty' version on the PPA, and each time I try to dput the 'precise' version it indicates that the orig tarball already exists and the one being uploaded differs [18:00] I went and downloaded the orig tarball associated with the trusty one, imported it into my upstream/ branch, and rebuilt the source from there and it still says it differs [18:01] at this point I'm not quite sure what I'm doing wrong, it doesn't seem like they _could_ differ [18:03] you can't upload the same source twice [18:03] the same orig.tar.gz that is [18:05] dobey: but both trusty and precise versions are based on the same orig source, is there a way to avoid dput uploading that file? [18:05] mbroadst: are you building the source with -sa option to debbuild? [18:11] ah hm no [18:11] I was just passing -S into gbp buildpackage [18:11] ok, then you probably have done something that caused the orig.tar.gz to be different than the previous upload [18:12] and the error you're actually getting is that it already exists and you're trying to upload different contents [18:14] but how's that possible though? it says its generating the orig.tar.gz from upstream/, I just downloaded the actual orig.tar.gz and import-orig'd that into upstream/ [18:15] i don't know what you're doing exactly, but are you building a package that is format native? [18:17] no its format is quilt [18:17] (I'm sorry this project was sort of dumped on me, I'm trying to catch up) [18:19] you did apt-get source, imported that to bzr, and then are trying to build a source package from that? [18:20] I've got this repo: https://github.com/mbroadst/debian-qpid-proton [18:21] and the "trusty" branch works, upstream points to version 0.10 of proton that was downloaded, as well as upstream/0.10 [18:21] the precise branch had to be imported using 'gbp import-dsc --debian-branch=precise', and then I merged in upstream and updated the patches [18:22] because the previous precise release was for verison 0.9 [18:24] the two versions share a common codebase, but the precise version needs a single patch applied to it [18:25] I presume I've done that all wrong :) [18:53] dobey: any thoughts? [18:54] I just went through the process from scratch, this time completely copying the existing trust branch and building from that to no avail [18:54] it just seems impossible that they are actually generating different orig.tar.gz files [18:54] and yet they are [18:54] i don't know what you're doing exactly, so i'm not sure why it's generating a different orig.tar.gz [18:55] dobey: if he doesn't precreate the orig.tar.gz from source code without the debian/ directory it *might* include that [18:55] no? [18:55] i'd say compare the orig.tar.gz that is failing for you, to the one already on the server, and see what the difference is [18:55] teward: or .git/ [18:55] dobey: that too, I actually torpedo that folder if it exists [18:55] AND i keep the debian/ folder out of the tarball [18:56] and always generate the orig tarball from just the source [18:56] (debuild -S creates the debian part as its own tarball strangely enough when I run it) [18:56] I just unpacked them both next to each other and they were identical [18:56] so frustrating.. [18:56] yes, it should create debian.tar.gz for format 3.0 packages [18:57] mbroadst: are the md5sums identical? [18:58] nope [18:59] now to see what else is screwed up here.. [18:59] mbroadst: open the orig.tar.gz and extract it. Do you have a .git or debian/ folder in there? [19:00] yeah, make sure the hidden files or debian/ dir are not in the new orig.tar.gz [19:00] no, neither [19:01] absolutely bizarre, diff -arq from-build from-apt results in 0 differences [19:02] as in, once they've both been extracted [19:02] perhaps the timestamp in like gzip? [19:03] I guess this would just work if I manually place the orig.tar.gz before the dput [19:03] i'mma try and replicate your steps if you don't mind? [19:04] sure [19:04] (btw the documentation on launchpad itself suggests just downloading the orig.tar.gz and placing it by hand..) [19:07] annd that worked [19:07] *sigh* [19:08] seriously I give it up to you guys maintaining packages in this process, it's been very exhausting :) [19:08] well [19:08] i have an idea how to produce pristine-tarball for you [19:08] but you'll hate it [19:08] and it's the 'manual' way [19:09] dobey: no way to force it to accept the version now that there's a copy already up on the PPA right? [19:09] teward: delete the orig.tar.gz from the .dsc i guess? [19:10] possibly [19:10] and/or source.changes [19:10] i think the problem is that it had to recreate the orig.tar.gz [19:10] mmm [19:10] so it's including it in the upload [19:10] probably the case [19:11] *shrug* [19:11] i can't really help any further though :) [19:11] yep [19:11] yeah I think what happened was that I deleted the orig.tar.gz in the level above the package dir (where it builds all the artifacs) as a sort of OCD measure [19:12] so it rebuilt the orig.tar.gz, and gzip added a timestamp to that [19:12] so the md5s _would_ be different, even though the contents are identical [19:12] and afiact launchpad is checking checksums not contents [19:12] or more likely, it was compressed at a different level [19:13] which would result in different contents [19:13] http://serverfault.com/questions/110208/different-md5sums-for-same-tar-contents [19:13] mbroadst: it compares contents of the resulting .gz, not of the unpacked tarball [19:14] and i went the manual route - grabbed source, built orig tarball, modified debian/ and pushed to a pristine PPA, and I know that method works xD [19:14] * teward is bored :) [19:14] point not withstanding there's still a conflict somewhere along the line, making sure your orig.tar.gz is the pristine source code helps a little, IMO, even if it's an extra manual step [19:16] mbroadst: i think you'll have bigger concerns than a failed orig tarball [19:16] FTBFS on precise [19:16] both amd64 and i386 [19:17] mbroadst: https://launchpad.net/~teward/+archive/ubuntu/qpid-proton/+packages if you're curious where I get that info from [19:17] but meh [19:17] mbroadst: the second tricky part was the versioning, PPAs can't have two versionstrings for the same package for different releases iirc [19:17] dobey: i.e. 1.1.0-1 can't be uploaded twice (once for Precise, once for Trusty, if they both have to build separately?) [19:20] mbroadst: granted i pulled master for those tests, but i don't see a precise branch anywhere either. [19:23] teward: correct [19:23] dobey: that's what i thought, just wanted to confirm :) [19:23] oop low power in my laptop lol [19:23] appending ~12.04.1 and ~14.04.1 to the version would help there [19:24] mhm [19:24] i use +trusty0 or +precise0 because nginx packaging is weirdly done but meh [19:24] but that's just for nginx [19:24] there's multiple ways to do the version string though [19:24] :) [19:29] teward: man the main page said it passed [19:29] mbroadst: what main page where [19:29] back to the drawing board :) [19:29] you should answer questions [19:29] IMO [19:30] mbroadst: i have build failure logs if you want [19:30] yeah I can fix that, it looks like the wrong patch was applied [19:30] mbroadst: https://launchpadlibrarian.net/216090493/buildlog_ubuntu-precise-amd64.qpid-proton_0.10-1~precise~ppa0_BUILDING.txt.gz and https://launchpadlibrarian.net/216090570/buildlog_ubuntu-precise-i386.qpid-proton_0.10-1~precise~ppa0_BUILDING.txt.gz [19:30] if you look here: https://launchpad.net/~qpid/+archive/ubuntu/testing [19:30] mbroadst: any patches applied now have to be applied through quilt [19:30] or a version bump :P [19:30] "latest updates" proton built fine for precise [19:31] :P [19:31] oh maybe you grabbed the source before my update [19:31] mbroadst: well there you go [19:31] mbroadst: probably did, but meh [19:31] in any case [19:31] * teward yawns [19:31] sorry I'm a little scatterbrained :) [19:31] i'mma go do something else now [19:31] thanks for the help [19:32] mbroadst: you're welcome. my advice for making a pristine tarball: [19:33] git clone; mv debian-qpid-proton qpid-proton-VERSIONNUMBER; cd qpid-proton-VERSIONNUMBER; mv ./debian ..; cd ..; tar czvf qpid-proton_VERSIONNUMBER.orig.tar.gz qpid-proton-VERSIONUMBER; mv ./debian qpid-proton-VERSIONNUMBER; [19:33] debuild [19:34] done [19:34] eww splits [19:35] yeah seems like a saner alternative [19:59] mbroadst: using pristine-tar would have made your life much easier [20:00] (tool that efficiently automates the process of representing how to get from a branch with orig contents to a byte-for-byte identical orig.tar.gz) [20:01] gbp probably integrates with it too [20:01] I know git-dpm does [20:29] I have a folder of code, which I currently have in bzr in a junk branch on launchpad. I have created a proper Launchpad project for it, and now I want the code in there. What's the best way to do this? I could, in the project on LP, import the branch from my junk branch, but that won't change the branch on my computer; I could (perhaps? don't know?) just bzr push lp:projectname from the folder on the computer and th [20:29] en it all works? Not sure what to do here. [20:30] aquarius: bzr push --remember yes [20:30] aquarius: doing anything on the launchpad UI itself will not modify your local copy at all [20:31] that's all? Does creating the project on LP create the right receiving environment that I can just push to it? [20:31] I am not sure of my vocab here :) [20:32] aquarius, it does [20:32] nice. [20:32] --remember is so bzr pushes there from then on [20:32] you'll have to push to lp:~aquarius/project/name first [20:32] ah, will I? [20:33] you can't push to lp:foo without first creating the branch and linking it to the trunk series as the development focus [20:33] but you can just create an empty branch on lp to do that if you want, and then push --overwrite --use-existing --remember [20:35] dobey, so, I should do "bzr push --remember lp:~sil/wifitransfer/trunk"? and then set that pushed branch as the development focus? [20:36] aquarius: yes [20:37] aquarius, and from then on, lp:wifitransfer will be a thing [20:41] * aquarius does so [20:44] dobey: not in fact true [20:44] cjwatson: what's not? [20:45] if you push to lp:foo, it doesn't already exist, and you have necessary privileges, then it'll autocreate a branch name with some unused name based on "trunk" and link it to lp:foo for you [20:45] cjwatson: oh, i wasn't aware of that. how long has that been the case? [20:46] *magic* [20:46] dobey: since about August 2010, I believe [20:47] oh, wow [20:47] a similar thing works with git [20:47] good to know :) [20:48] (which is why I know about this; I spent some time understanding that code in order to implement the same kind of thing for git) [20:48] it's all buried in lib/lp/code/xmlrpc/ because reasons [20:49] tmi ;) [20:50] aquarius: fwiw it would also have been possible to move it around from "Change details" in the LP web UI, and then "bzr push --remember" wouldn't need to re-push it [20:50] aquarius: presumably now you'll want to delete the junk branch [20:50] ah. I did wonder whether that was doable. Well, I have pushed it now, anyway; now to set it as development focus [20:52] yay, that seems to have worked [21:04] goldarnit. I made the app name a translatable string [21:04] now to work out how to fix that [21:08] make it not be [21:13] yup. Fixed. === cory_fu is now known as cory_out